Kaspersky Securelist

Syndikovat obsah Securelist
Aktualizace: 12 min 26 sek zpět

Targeted Malware Reverse Engineering Workshop follow-up. Part 1

19 Duben, 2021 - 13:30

On April 8, 2021, we conducted a webinar with Ivan Kwiatkowski and Denis Legezo, Senior Security Researchers from our Global Research & Analysis Team (GReAT), who gave live workshops on practical disassembling, decrypting and deobfuscating authentic malware cases, moderated by GReAT’s own Dan Demeter.

Ivan demonstrated how to strip the obfuscation from the recently discovered Cycldek-related tool, while Denis presented an exercise on reversing the MontysThree’s malware  steganography algorithm. The experts also had a fireside chat with our guest Igor Skochinsky of Hex-Rays.

On top of that, Ivan and Denis introduced the new Targeted Malware Reverse Engineering online self-study course, into which they have squeezed 10 years of their cybersecurity experience. This intermediate-level training is designed for those seeking confidence and practical experience in malware analysis. It includes in-depth analysis of ten fresh real-life targeted malware cases, like MontysThree, LuckyMouse and Lazarus, hands-on learning with an array of reverse engineering tools, including IDA Pro, Hex-Rays decompiler, Hiew, 010 Editor, and 100 hours of virtual lab practice.

In case you missed the webinar – or if you attended but want to watch it again – you can find the video here: Targeted Malware Reverse Engineering Workshop (brighttalk.com).

With so many questions collected during the webinar – thank you all for your active participation! – we lacked the time to answer them all online, we promised we would come up with this blogpost.

Questions on the Cycldek-related tool analysis
  1. How do you decide whether the Cycldek-actors have adopted the DLL side-loading triad technique, or the actors normally using the DLL side-loading triad have adopted the design considerations from Cycldek?
    Ivan: It is precisely because we cannot really differentiate between the two that we have been very careful with the attribution of this specific campaign. The best we can say at the moment is that the threat actor behind it is related to Cycldek.
    Denis: Even in our training there is another track with .dll search order hijacking – LuckyMouse. I really would not recommend anyone to build attribution based on such a technique, because it’s super wide-spread among the Chinese-speaking actors.
  2. Does the script work automatically, or do you have to add information about the specific code you are working with?
    Ivan: The script shown in the webinar was written solely for the specific sample used in the demonstration. I prefer to write small programs addressing very specific issues at first, and only move on to developing generic frameworks when I have to, which is not the case for opaque predicates.
  3. Is the deobfuscation script for the shellcode publicly available?
    Ivan: It is derived from a publicly available script. However, my modifications were not made public; if they were, it would make the training a little too easy, wouldn’t it?
  4. Decryption/deobfuscation seems to be very labor-intensive. Have you guys experimented with symbolic execution in order to automate the process? Have you built a framework that you use against multiple families and (data&code) obfuscation or you build tools on ‘as needed’ basis?
    Ivan: I have always found it quicker to just write quick scripts to solve the problem instead of spending time on diving into symbolic execution. Same goes for generic frameworks, but who knows? Maybe one day I will need one.
    Denis: Decryption/deobfuscation is mostly case-based, I agree, but we also have disassembler plugins to facilitate such tasks. By the way, such a code base and the habits are the reasons that create the threshold to change the disassembler. We have internal framework for asm layer decryption, you will meet him in advanced course, but it’s up to researcher to use it or not.
  5. Any insight into the success rate of this campaign?
    Ivan: We were able to identify about a dozen organizations attacked during this campaign. If you want to know more about our findings, please have a look at our blogpost.
  6. Any hint on the code pattern that helped you connect with the Cycledek campaign?
    Ivan: You can find more about this in our blogpost. Even more details are available through our private reporting service. Generally speaking, we have a tool called KTAE that performs this task, and of course the memory of samples we have worked on in the past.
  7. About the jump instructions that lead to the same spot – how were they injected there? Manually using a binary editor?
    Ivan: The opaque predicates added in the Cycldek shellcode were almost certainly inserted using an automated tool.
  8. I am one of the people using the assembly view. After the noping stage usually I have to suffer the long scrolling. You mentioned there is a way to fix this?”
    Ivan: Check out this script I published on GitHub a couple of months ago.
  9. Can xmm* registers and Pxor be used as code patterns Yara signatures?
    Ivan: This is in fact one of the signatures I wrote for this piece of malware.
Questions on analysis of the MontysThree’s malware steganography algorithm
  1. Do you think there was a practical reason to use steganography as obfuscation, or the malware developer did it just for fun?
    Denis: In my experience, most steps the malefactors take are on purpose, not for fun. With steganography they are trying to fool the network security systems like IDS/IPS: bitmaps are not too suspicious for them. Let me also add that the campaign operators are human, too, so now and again there will be Easter eggs in their products — for example, take a look at the Topinambour track and the phrases used as decryption keys and beaconing.
  2. What image steganography algorithm have you seen hiding in the wild recently, other than LSB?
    Denis: As far as I know, it is LSB alright — Microcin, MontysThree. I would expect some tools to be creating such images for the operators. But take a look at the function we ended during the short workshop: depending on the decrypted steganography parameters, it could be not just LSB, but the “less significant half a byte” as well.
  3. Are there any recent malware samples incorporating network steganography in their C&C-channels, the way the DoublePulsar backdoor did using SMB back in 2017?
    Denis: I suppose you mean the broken SMB packages. Yes, the last trick of the kind I saw was the rare use of HTTP statuses as C2 commands. You might be surprised to learn how many of them there are in RFCs and how strange some of them are, like “I’m the kettle”.
Reverse Engineering: how to start a career, working routines, the future of the profession
  1. How does one get into malware reverse engineering? What are the good resources to study? How can one find interesting malware samples?
    Ivan: You can find a solid introduction at https://beginners.re/. Next, check out https://crackmes.one/ which contains many programs designed to be reverse-engineered, so one can finally move on to malware samples. Worry not about finding the “interesting” ones early on; just try to get good at it, document what you do, and you will find yourself in no time being able to access all the data you could wish for.
    Denis: Do you like meditating on the code and trying to understand it? Then I suppose you already have everything you need. I think you should not bother looking for interesting ones in the beginning (if I get your question right) – everything will do. In my experience, the the ones on which you would progress more are written by professional programmers, not malware writers, because they just cannot do away with their habit of structuring the data and code, making it multi-thread safe, etc.
  2. Now an experienced malware reverse engineer, where did you start from? Do you have any solid math/programming background from where you moved on to malware reverse engineering? Or what would be the typical path?
    Ivan: I have a software engineering background, and my math expertise is shaky at best. After having met so many people in this field, I can say confidently that there is no typical path beyond being passionate about the subject.
    Denis: Personally I have a math/programming background, but I couldn’t agree more: it’s more about passion than any scientific education.
  3. If you are reverse engineering malware, do you work as a team?
    Ivan: While several researchers can investigate a campaign together, I usually work on samples alone. The time it takes to wrap up a case may vary between a week and several months, depending on the complexity of the investigation!
    Denis: Reversing itself is not the task that is easy to distribute/parallel. In my experience, you would spend more time organizing the process than benefit from the work of several reversers. Typically, I do this part alone, but research is not limited to binary analysis: the quest, the sharing of previous experiences with the same malware/tools, and so forth — it is a team game.
  4. What do you think about AI? Would it help to automate the reverse engineering work?
    Ivan: I think at the moment it is still a lot more A than I. I keep hearing sales pitches about how it will revolutionize the infosec industry and I do not want to dismiss them outright. I am sure there are a number of tasks, such as malware classification, where AI could be helpful. Let’s see what the future brings!
    Denis: OK, do you use any AI-based code similarity, for example? I do, and you know — my impression so far is we still need meat-based engineers who understand how it works to use it right.
  5. How helpful is static analysis, considering the multiple advanced sandboxing solutions available today?
    Ivan: Sandboxing and static analysis will always serve complementary purposes. Static analysis is fast and does not require running the sample. It is great to quickly gather information about what a program might do or for triage. Dynamic analysis takes longer, yields more details, but gives malware an opportunity to detect the sandboxed environment. Then, at the very end, you do static analysis again, which involves reverse-engineering the program with a disassembler and takes the longest. All have their uses.
    Denis: Sometimes you need static analysis because of the multiple advanced anti-sandboxing tricks out there. You also reveal far more details through static analysis if you want to create better Yara rules or distinguish a specific part of custom code to attribute samples to specific developers. So it is up to you how deep the rabbit hole should be.
Tips on tools, IDA and other things
  1. Do you contribute to Lumina server? Does Kaspersky have any similar public servers to help us during our analysis?
    Ivan: My understanding is that Lumina is most helpful when used by a critical mass of users. As such, I do not think it would make sense to fragment the community across multiple servers. If you are willing to share metadata about the programs you are working on with third-parties, I would recommend to simply go with an Hex-Rays’ instance.
    Denis: No, I have never contributed to Lumina so far. I don’t think it is going to be too popular for threat intelligence, but let us wait and see — public Yara repositories are there, so maybe code snippets might also meet the community’s needs.
  2. What tools and techniques do you recommend for calculating the code similarity of samples? Is this possible with IDA Pro?
    Ivan: For this, we have developed a commercial solution called KTAE. That’s what we regularly use internally.
    Denis: Personally, I am using our KTAE. As far as I know, the creating of custom FLIRT signatures right in IDA could partially cover this need.
  3. Is there any specific reason why you are using IDA under wine? Does it have anything to do with the type of samples you are analyzing?
    Denis: I used to have Windows IDA licenses and Linux OS historically, so wine is my way of using disassembler. It does not affect your analysis anyway — choose any samples you want under any OS.
  4. What is your favorite IDA Pro plugin and why?
    Ivan: One of the internal plugins developed by Kaspersky. Other than that, I use x64dbgida regularly and have heard great things about Labeless.
    Denis: For sure our internal plugins. And it’s not because of the authorship, they just perfectly meet our needs.
  5. Do you have a plan to create/open an API so we can create our own processor modules for decompilers (like SLEIGH in Ghidra)? The goal being to analyze VM-based obfuscation.
    Igor: Unlikely to happen in the near future but that’s something we’re definitely keeping in our minds.

If you have any more questions about Ivan’s workshop on the Cycldek-related tool or about the Targeted Malware Reverse Engineering online course, please feel free to drop us a line in the comments box below or contact us on Twitter: @JusticeRage, @legezo and @IgorSkochinsky. We will answer the rest of the questions in our next blogpost – stay tuned!

Zero-day vulnerability in Desktop Window Manager (CVE-2021-28310) used in the wild

13 Duben, 2021 - 19:35

While analyzing the CVE-2021-1732 exploit originally discovered by the DBAPPSecurity Threat Intelligence Center and used by the BITTER APT group, we discovered another zero-day exploit we believe is linked to the same actor. We reported this new exploit to Microsoft in February and after confirmation that it is indeed a zero-day, it received the designation CVE-2021-28310. Microsoft released a patch to this vulnerability as a part of its April security updates.

We believe this exploit is used in the wild, potentially by several threat actors. It is an escalation of privilege (EoP) exploit that is likely used together with other browser exploits to escape sandboxes or get system privileges for further access. Unfortunately, we weren’t able to capture a full chain, so we don’t know if the exploit is used with another browser zero-day, or coupled with known, patched vulnerabilities.

The exploit was initially identified by our advanced exploit prevention technology and related detection records. In fact, over the past few years, we have built a multitude of exploit protection technologies into our products that have detected several zero-days, proving their effectiveness time and again. We will continue to improve defenses for our users by enhancing technologies and working with third-party vendors to patch vulnerabilities, making the internet more secure for everyone. In this blog we provide a technical analysis of the vulnerability and how the bad guys exploited it. More information about BITTER APT and IOCs are available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Technical details

CVE-2021-28310 is an out-of-bounds (OOB) write vulnerability in dwmcore.dll, which is part of Desktop Window Manager (dwm.exe). Due to the lack of bounds checking, attackers are able to create a situation that allows them to write controlled data at a controlled offset using DirectComposition API. DirectComposition is a Windows component that was introduced in Windows 8 to enable bitmap composition with transforms, effects and animations, with support for bitmaps of different sources (GDI, DirectX, etc.). We’ve already published a blogpost about in-the-wild zero-days abusing DirectComposition API. DirectComposition API is implemented by the win32kbase.sys driver and the names of all related syscalls start with the string “NtDComposition”.

DirectComposition syscalls in the win32kbase.sys driver

For exploitation only three syscalls are required: NtDCompositionCreateChannel, NtDCompositionProcessChannelBatchBuffer and NtDCompositionCommitChannel. The NtDCompositionCreateChannel syscall initiates a channel that can be used together with the NtDCompositionProcessChannelBatchBuffer syscall to send multiple DirectComposition commands in one go for processing by the kernel in a batch mode. For this to work, commands need to be written sequentially in a special buffer mapped by NtDCompositionCreateChannel syscall. Each command has its own format with a variable length and list of parameters.

enum DCOMPOSITION_COMMAND_ID { ProcessCommandBufferIterator, CreateResource, OpenSharedResource, ReleaseResource, GetAnimationTime, CapturePointer, OpenSharedResourceHandle, SetResourceCallbackId, SetResourceIntegerProperty, SetResourceFloatProperty, SetResourceHandleProperty, SetResourceHandleArrayProperty, SetResourceBufferProperty, SetResourceReferenceProperty, SetResourceReferenceArrayProperty, SetResourceAnimationProperty, SetResourceDeletedNotificationTag, AddVisualChild, RedirectMouseToHwnd, SetVisualInputSink, RemoveVisualChild };

List of command IDs supported by the function DirectComposition::CApplicationChannel::ProcessCommandBufferIterator

While these commands are processed by the kernel, they are also serialized into another format and passed by the Local Procedure Call (LPC) protocol to the Desktop Window Manager (dwm.exe) process for rendering to the screen. This procedure could be initiated by the third syscall – NtDCompositionCommitChannel.

To trigger the vulnerability the discovered exploit uses three types of commands: CreateResource, ReleaseResource and SetResourceBufferProperty.

void CreateResourceCmd(int resourceId) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = CreateResource; buf[1] = resourceId; buf[2] = PropertySet; // MIL_RESOURCE_TYPE buf[3] = FALSE; BatchLength += 16; } void ReleaseResourceCmd(int resourceId) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = ReleaseResource; buf[1] = resourceId; BatchLength += 8; } void SetPropertyCmd(int resourceId, bool update, int propertyId, int storageOffset, int hidword, int lodword) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = SetResourceBufferProperty; buf[1] = resourceId; buf[2] = update; buf[3] = 20; buf[4] = propertyId; buf[5] = storageOffset; buf[6] = _D2DVector2; // DCOMPOSITION_EXPRESSION_TYPE buf[7] = hidword; buf[8] = lodword; BatchLength += 36; }

Format of commands used in exploitation

Let’s take a look at the function CPropertySet::ProcessSetPropertyValue in dwmcore.dll. This function is responsible for processing the SetResourceBufferProperty command. We are most interested in the code responsible for handling DCOMPOSITION_EXPRESSION_TYPE = D2DVector2.

int CPropertySet::ProcessSetPropertyValue(CPropertySet *this, ...) { ... if (expression_type == _D2DVector2) { if (!update) { CPropertySet::AddProperty<D2DVector2>(this, propertyId, storageOffset, _D2DVector2, value); } else { if ( storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF ) { goto fail; } CPropertySet::UpdateProperty<D2DVector2>(this, propertyId, _D2DVector2, value); } } ... } int CPropertySet::AddProperty<D2DVector2>(CResource *this, unsigned int propertyId, int storageOffset, int type, _QWORD *value) { int propertyIdAdded; int result = PropertySetStorage<DynArrayNoZero,PropertySetUserModeAllocator>::AddProperty<D2DVector2>( this->propertiesData, type, value, &propertyIdAdded); if ( result < 0 ) { return result; } if ( propertyId != propertyIdAdded || storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF ) { return 0x88980403; } result = CPropertySet::PropertyUpdated<D2DMatrix>(this, propertyId); if ( result < 0 ) { return result; } return 0; } int CPropertySet::UpdateProperty<D2DVector2>(CResource *this, unsigned int propertyId, int type, _QWORD *value) { if ( this->properties[propertyId]->type == type ) { *(_QWORD *)(this->propertiesData + (this->properties[propertyId]->offset & 0x1FFFFFFF)) = *value; int result = CPropertySet::PropertyUpdated<D2DMatrix>(this, propertyId); if ( result < 0 ) { return result; } return 0; } else { return 0x80070057; } }

Processing of the SetResourceBufferProperty (D2DVector2) command in dwmcore.dll

For the SetResourceBufferProperty command with the expression type set to D2DVector2, the function CPropertySet::ProcessSetPropertyValue(…) would either call CPropertySet::AddProperty<D2DVector2>(…) or CPropertySet::UpdateProperty<D2DVector2>(…) depending on whether the update flag is set in the command. The first thing that catches the eye is the way the new property is added in the CPropertySet::AddProperty<D2DVector2>(…) function. You can see that it adds a new property to the resource, but it only checks if the propertyId and storageOffset of a new property are equal to the provided values after the new property is added, and returns an error if that’s not the case. Checking something after a job is done is bad coding practice and can result in vulnerabilities. However, a real issue can be found in the CPropertySet::UpdateProperty<D2DVector2>(…) function. No check takes place that will ensure if the provided propertyId is less than the count of properties added to the resource. As a result, an attacker can use this function to perform an OOB write past the propertiesData buffer if it manages to bypass two additional checks for data inside the properties array.

(1) storageOffset == this->properties[propertyId]->offset & 0x1FFFFFFF (2) this->properties[propertyId]->type == type

Conditions which need to be met for exploitation in dwmcore.dll

These checks could be bypassed if an attacker is able to allocate and release objects in the dwm.exe process to groom heap into the desired state and spray memory at specific locations with fake properties. The discovered exploit manages to do this using the CreateResource, ReleaseResource and SetResourceBufferProperty commands.

At the time of writing, we still hadn’t analyzed the updated binaries that are fixing this vulnerability, but to exclude the possibility of other variants for this vulnerability Microsoft would need to check the count of properties for other expression types as well.

Even with the above issues in dwmcore.dll, if the desired memory state is achieved to bypass the previously mentioned checks and a batch of commands are issued to trigger the vulnerability, it still won’t be triggered because there is one more thing preventing it from happening.

As mentioned above, commands are first processed by the kernel and only after that are they sent to Desktop Window Manager (dwm.exe). This means that if you try to send a command with an invalid propertyId, NtDCompositionProcessChannelBatchBuffer syscall will return an error and the command will not be passed to the dwm.exe process. SetResourceBufferProperty commands with expression type set to D2DVector2 are processed in the win32kbase.sys driver with the functions DirectComposition::CPropertySetMarshaler::AddProperty<D2DVector2>(…) and DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(…), which are very similar to those present in dwmcore.dll (it’s quite likely they were copy-pasted). However, the kernel version of the UpdateProperty<D2DVector2> function has one notable difference – it actually checks the count of properties added to the resource.

int DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(DirectComposition::CPropertySetMarshaler *this, unsigned int *commandParams, _QWORD *value) { unsigned int propertyId = commandParams[0]; unsigned int storageOffset = commandParams[1]; unsigned int type = commandParams[2]; if ( propertyId >= this->propertiesCount || storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF) || type != this->properties[propertyId]->type ) { return 0xC000000D; } else { *(_QWORD *)(this->propertiesData + (this->properties[propertyId]->offset & 0x1FFFFFFF)) = *value; ... } return 0; }

DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(…) in win32kbase.sys

The check for propertiesCount in the kernel mode version of the UpdateProperty<D2DVector2> function prevents further processing of a malicious command by its user mode twin and mitigates the vulnerability, but this is where DirectComposition::CPropertySetMarshaler::AddProperty<D2DVector2>(…) comes in to play. The kernel version of the AddProperty<D2DVector2> function works exactly like its user mode variant and it also applies the same behavior of checking property after it has already been added and returns an error if propertyId and storageOffset of the created property do not match the provided values. Because of this, it’s possible to use the AddProperty<D2DVector2> function to add a new property and force the function to return an error and cause inconsistency between the number of properties assigned to the same resource in kernel mode/user mode. The propertiesCount check in the kernel could be bypassed this way and malicious commands would be passed to Desktop Window Manager (dwm.exe).

Inconsistency between the number of properties assigned to the same resource in kernel mode/user mode could be a source of other vulnerabilities, so we recommend Microsoft to change the behavior of the AddProperty function and check properties before they are added.

The whole exploitation process for the discovered exploit is as follows:

  1. Create a large number of resources with properties of specific size to get heap into predictable state.
  2. Create additional resources with properties of specific size and content to spray memory at specific locations with fake properties.
  3. Release resources created at stage 2.
  4. Create additional resources with properties. These resources will be used to perform OOB writes.
  5. Make holes among resources created at stage 1.
  6. Create additional properties for resources created at stage 4. Their buffers are expected to be allocated at specific locations.
  7. Create “special” properties to cause inconsistency between the number of properties assigned to the same resource in kernel mode/user mode for resources created at stage 4.
  8. Use OOB write vulnerability to write shellcode, create an object and get code execution.
  9. Inject additional shellcode into another system process.

Kaspersky products detect this exploit with the verdicts:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

 

Malicious code in APKPure app

9 Duben, 2021 - 18:58

Recently, we’ve found malicious code in version 3.17.18 of the official client of the APKPure app store. The app is not on Google Play, but it is itself a quite a popular app store around the world. Most likely, its infection is a repeat of the CamScanner incident, when the developer implemented a new adware SDK from an unverified source.

We notified the developers about the infection on April 8. APKPure confirmed the issue and promptly fixed it with the release of version 3.17.19.

In terms of functionality, the malicious code embedded in APKPure is standard for this type of threat. When the app starts, the payload is decrypted and launched. In this case, it is located in a long string in the app code.

The payload collects information about the user device and sends it to the C&C server.

Next, depending on the response received, the malware can:

    • Show ads when the device is unlocked.

    • Open browser pages with ads repeatedly.

    • Load additional executable modules.

In our case, a Trojan was loaded that has much in common with the notorious Triada malware and can perform a range of actions: from displaying and clicking ads to signing up for paid subscriptions and downloading other malware.


Depending on the OS version, the Trojan can inflict various forms of damage on the victim. APKPure users with current Android versions mostly risk having paid subscriptions and intrusive ads appear from nowhere. Users of smartphones who do not receive security updates are less fortunate: in outdated versions of the OS, the malware is capable of not only loading additional apps, but installing them on the system partition. This can result in an unremovable Trojan like xHelper getting onto the device.

Kaspersky solutions detect the malicious implant as HEUR:Trojan-Dropper.AndroidOS.Triada.ap.

If you use APKPure, we recommend immediately deleting the infected app and installing the “clean” 3.17.19 version. In addition, scan the system for other Trojans using a reliable security solution, such as Kaspersky Internet Security for Android.

IOCs

APKPure app
2cfaedcf879c62f5a50b42cbb0a7a499
718aecd85e9f1219f3fc05ef156d3acf
ceac990b3df466c0d23e0b7f588d1407
deac06ab75be80339c034e266dddbc9f
f64d43c64b8a39313409db2c846b3ee9

Payload
31e49ac1902b415e6716bc3fb048f381

Downloaded malware
5f9085a5e5e17cb1f6e387a901e765cf

C&C
https://wcf.seven1029[.]com
http://foodin[.]site/UploadFiles/20210406052812.apk

The leap of a Cycldek-related threat actor

5 Duben, 2021 - 12:00

Introduction

In the nebula of Chinese-speaking threat actors, it is quite common to see tools and methodologies being shared. One such example of this is the infamous “DLL side-loading triad”: a legitimate executable, a malicious DLL to be sideloaded by it, and an encoded payload, generally dropped from a self-extracting archive. Initially considered to be the signature of LuckyMouse, we observed other groups starting to use similar “triads” such as HoneyMyte. While it implies that it is not possible to attribute attacks based on this technique alone, it also follows that efficient detection of such triads reveals more and more malicious activity.

The investigation described in this article started with one such file which caught our attention due to the various improvements it brought to this well-known infection vector.

FoundCore Loader

This malware sample was discovered in the context of an attack against a high-profile organization located in Vietnam. From a high-level perspective, the infection chain follows the expected execution flow:

After being loaded by a legitimate component from Microsoft Outlook (FINDER.exe, MD5 9F1D6B2D45F1173215439BCC4B00B6E3), outlib.dll (MD5 F267B1D3B3E16BE366025B11176D2ECB) hijacks the intended execution flow of the program to decode and run a shellcode placed in a binary file, rdmin.src (MD5 DF46DA80909A6A641116CB90FA7B8258). Such shellcodes that we had seen so far, however, did not involve any form of obfuscation. So, it was a rather unpleasant surprise for us when we discovered the first instructions:

Experienced reverse-engineers will immediately recognize disassembler-desynchronizing constructs in the screenshot above. The conditional jumps placed at offsets 7 and 9 appear to land in the middle of an address (as evidenced by the label loc_B+1), which is highly atypical for well-behaved assembly code. Immediately after, we note the presence of a call instruction whose destination (highlighted in red) is identified as bogus by IDA Pro, and the code that follows doesn’t make any sense.

Explaining what is going on requires taking a step back and providing a bit of background about how disassemblers work. At the risk of oversimplifying, flow-oriented disassemblers make a number of assumptions when processing files. One of them is that, when they encounter a conditional jump, they start disassembling the “false” branch first, and come back to the “true” branch later on. This process is better evidenced by looking at the opcodes corresponding to the code displayed above, again starting from offset 7:

It is now more obvious that there are two ways to interpret the code above: the disassembler can either start from “E8”, or from “81” – by default, IDA will choose the latter: E8 is in fact the opcode for the call instruction. But astute readers will notice that “JLE” (jump if lower or equal) and “JG” (jump if greater) are opposite conditions: no matter what, one of those will always be true and as such the actual code, as seen by the CPU during the execution, will start with the byte “81”. Such constructs are called opaque predicates, and this E8 byte in the middle was only added there in order to trick the disassembler.

Defeating this trick is but a trivial matter for IDA Pro, as it is possible to manually correct the disassembling mistake. However, it was immediately obvious that the shellcode had been processed by an automated obfuscation tool. Opaque predicates, sometimes in multiples, and dead code were inserted between every single instruction of the program. In the end, cleaning up the program automatically was the only practical approach, and we did so by modifying an existing script for the FinSpy malware family created by the respected reverse-engineer Rolf Rolles.

This step allowed us to discover the shellcode’s purpose: to decrypt and decompress the final payload, using a combination of RC4 and LZNT1. Even then, it turned out that the attackers had more tricks up their sleeve. Normally, at this stage, one would have expected to find a PE file that the shellcode would load into memory. But instead, this is what we got:


The recovered file was indeed a PE, but it turned out that most of its headers had been scrubbed. In fact, even the scarce ones remaining contained incoherent values – for instance, here, a number of declared sections equal to 0xAD4D. Since it is the shellcode (and not the Windows loader) that prepares this file for execution, it doesn’t matter that some information, such as the magic numbers, is missing. As for the erroneous values, it turned out that the shellcode was fixing them on the fly using hardcoded operations:

for ( i = 0; ; ++i ) // Iterate on the sections { // [...] // Stop when all sections have been read if ( i >= pe->pe_header_addr->FileHeader.NumberOfSections - 44361 ) break; // [...] }

For instance, in the decompiled code above (as for all references to the file’s number of sections) the value read in the headers is subtracted by 44361. For the attackers, the advantage is two-fold. First, it makes acquiring the final payload statically a lot more difficult for potential reverse-engineers. Second, it also ensures that the various components of the toolchain remain tightly coupled to each other. If only a single one of them finds itself uploaded to a multi-scanner website, it will be unexploitable for defenders. This is a design philosophy that we had observed from the LuckyMouse APT in the past, and is manifest in other parts of this toolchain too, as we will see later on. Eventually, we were able to reconstruct the file’s headers and move on with our analysis – but we found this loader so interesting from an educational standpoint that we decided to base one track of our online reverse-engineering course on it. For more detailed steps on how we approached this sample, please have a look at Targeted Malware Reverse Engineering.

FoundCore payload

The final payload is a remote administration tool that provides full control over the victim machine to its operators. Upon execution, this malware starts 4 threads:

  • The first one establishes persistence by creating a service.
  • The second one sets inconspicuous information for the service by changing its “Description”, “ImagePath”, “DisplayName” fields (among others).
  • The third sets an empty DACL (corresponding to the SDDL string “D:P”) to the image associated to the current process in order to prevent access to the underlying malicious file.
  • Finally, a worker thread bootstraps execution and establishes connection with the C2 server. Depending on its configuration, it may also inject a copy of itself to another process.

Communications with the server can take place either over raw TCP sockets encrypted with RC4, or via HTTPS. Commands supported by FoundCore include filesystem manipulation, process manipulation, screenshot captures and arbitrary command execution.

RoyalRoad documents, DropPhone and CoreLoader

Taking a step back from the FoundCore malware family, we looked into the various victims we were able to identify to try to gather information about the infection process. In the vast majority of the incidents we discovered, it turned out that FoundCore executions were preceded by the opening of a malicious RTF documents downloaded from static.phongay[.]com. They all were generated using RoyalRoad and attempt to exploit CVE-2018-0802.

Interestingly, while we would have expected them to contain decoy content, all of them were blank. We, therefore, hypothesize the existence of precursor documents, possibly delivered through spear-phishing, or precursor infections, which would trigger the download of one of these RTF files.

Successful exploitation leads to the deployment of yet another malware that we named DropPhone:

MD5 6E36369BF89916ABA49ECA3AF59D38C6 SHA1 C477B50AE66E7228164930117A7D36C53713A5F2 SHA256 F50AE4B25B891E95B57BD4391AEB629437A43664034630D593EB9846CADC9266 Creation time 2020-11-04 09:14:22 File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 56 KB

This C++ implant also comes in the form of a legitimate executable (DeElevate.exe, from the publisher StarDock) and a side-loaded DLL (DeElevator.dll). At this stage, we are left with more questions than answers when it comes to it. DropPhone fetches a file saved as data.dat from hxxps://cloud.cutepaty[.]com, but we were unable to obtain a copy of this file so far. Next, it expects to find a companion program in %AppData%\Microsoft\Installers\sdclt.exe, and will eventually terminate execution if it cannot find it.

Our hypothesis is that this last file could be an instance or variant of CoreLoader (which we will describe in a minute), but the only piece of data supporting this theory that we have at our disposal is that we found CoreLoader in this folder in a single occurrence.

DropPhone launches sdclt.exe, then collects environment information from the victim machine and sends it to DropBox. The last thing this implant does is delete data.dat without ever accessing its contents. We speculate that they are consumed by sdclt.exe, and that this is another way to lock together the execution of two components, frustrating the efforts of the reverse-engineers who are missing pieces of the puzzle – as is our case here.

MD5 1234A7AACAE14BDD94EEE6F44F7F4356 SHA1 34977E351C9D0E9155C6E016669A4F085B462762 SHA256 492D3B5BEB89C1ABF88FF866D200568E9CAD7BB299700AA29AB9004C32C7C805 Creation time 2020-11-21 03:47:14 File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 66 KB

Finally, CoreLoader, the last malware we found associated to this set of activity, is a simple shellcode loader which performs anti-analysis and loads additional code from a file named WsmRes.xsl. Again, this specific file eluded our attempts to catch it but we suspect it to be, one way or another, related to FoundCore (described in the previous section).

Overall, our current understanding of this complex toolchain is as follows. Dashed lines represent the components and links we are inferring, striped boxes represent the files we could not acquire.

Victimology and attribution

We observed this campaign between June 2020 and January 2021. According to our telemetry, dozens of organizations were affected. 80% of them are based in Vietnam and belong to the government or military sector, or are otherwise related to the health, diplomacy, education or political verticals. We also identified occasional targets in Central Asia and in Thailand.

For the reasons laid-out in the introduction, attribution based on tooling alone is risky when it comes to this nebula. At first glance, the use of a “triad”, the general design philosophy and the obvious effort spent to make reverse-engineering as complex as possible are reminiscent of LuckyMouse. However, we also observed code similarities between CoreLoader or FoundCore and programs associated with the Cycldek threat actor – namely, RedCore Loader (MD5: 1B6BCBB38921CAF347DF0A21955771A6).

While Cycldek was, so far, considered to be one of the lesser sophisticated threat actors from the Chinese-speaking nexus, its targeting is known to be consistent with what we observed in this campaign. Therefore, we are linking the activities described in this post with Cycldek with low confidence.

Conclusion

No matter which group orchestrated this campaign, it constitutes a significant step up in terms of sophistication. The toolchain presented here was willfully split into a series of interdependent components that function together as a whole. Single pieces are difficult – sometimes impossible – to analyze in isolation, because they rely on code or data provided at other stages of the infection chain. We regretfully admit that this strategy was partly successful in preventing us from obtaining a complete picture of this campaign. As such, this report is as much about the things we know as it is about figuring out what we don’t. We hereby extend our hand to fellow researchers who might be seeing other pieces of this vast puzzle, because we strongly believe that the challenges ahead of us can only be overcome through information sharing among trusted industry partners.

Some readers from other regions of the world might dismiss this local activity as irrelevant to their interests. We would advise them to take heed. Experience shows that regional threat actors sometimes widen their area of activity as their operational capabilities increase, and that tactics or tools are vastly shared across distinct actors or intrusion-sets that target different regions. Today, we see a group focused on South-East Asia taking a major leap forward. Tomorrow, they may decide they’re ready to take on the whole world.

Indicators of Compromise

File Hashes

F267B1D3B3E16BE366025B11176D2ECB FoundCore malicious DLL (outllib.dll) DF46DA80909A6A641116CB90FA7B8258 FoundCore companion file (rdmin.src) 6E36369BF89916ABA49ECA3AF59D38C6 DropPhone 60095B281E32DAD2B58A10005128B1C3 Malicious RTF document 1234A7AACAE14BDD94EEE6F44F7F4356 CoreLoader

Domains

phong.giaitrinuoc[.]com FoundCore C2 cloud.cutepaty[.]com DropPhone C2 static.phongay[.]com RTF document stager

Browser lockers: extortion disguised as a fine

2 Duben, 2021 - 12:00

Browser lockers (aka browlocks) are a class of online threats that prevent the victim from using the browser and demand a ransom. A locker is a fake page that dupes the user, under a fictitious pretext (loss of data, legal liability, etc.), into making a call or a money transfer, or giving out payment details. The “locking” consists of preventing the user from leaving the current tab, which displays intimidating messages, often with sound and visual effects.

This type of fraud is not new and has long been on the radar of researchers. The past decade has seen numerous browser locking campaigns targeting users worldwide. Despite its mature age, the threat has lost none of its popularity; on the contrary, the number of tricks used by scammers is only growing. They include imitating the “blue screen of death” (BSOD) in the browser, false warnings about system errors or detected viruses, threats to encrypt files, legal liability notices, and many others. In this post, we examine two families of lockers that mimic government websites.

Propagation methods

Both families spread mainly via advertising networks, primarily aimed at selling “adult” content and movies in an intrusive manner; for example, through tabs or windows that open on top of the visited site when loading a page with an embedded ad module (pop-ups) or after clicking anywhere on the page (click-unders). Presumably cybercriminals pay for ads to show browser lockers in pop-ups.

Family #1. Fake websites of the Russian Ministry of Internal Affairs: “Give us your money”

Members of the first family under consideration mimic the website of the Russian Ministry of Internal Affairs (MVD), and are thus aimed at users from Russia. In Q4 2020, more than 55,000 users encountered them.

Example of a fake MVD website

What the victim sees (and hears)

On landing on a fake browlock site, the user typically sees a warning, supposedly from the browser, saying that if they leave the page some changes might not be saved.

If the user simply closes the tab, nothing happens; but if they click anywhere on the page, the main content of the locker expands to full screen. As a result, an imitation of a computer screen with an open browser appears in front of the user: at the bottom is a taskbar with the Google Chrome icon, and at the top is an address bar displaying the real URL of the MVD. The notification on the page states that the device has been locked due to a violation of the law. Under the pretext of a fine, the victim is instructed to transfer a certain amount to a mobile account, ranging in size from 3,000 to 10,000 rubles (US$40–130). In case of refusal, the ransomwarers threaten file encryption, as well as criminal liability under Article 242 of the Russian Criminal Code. The page is accompanied by an audio recording with threats and a demand to pay the fine.

Technical details

The scammers use full-screen mode to make it difficult for the user to access the browser window controls and taskbar, and to create a locking effect. In addition, to convince the victim that the mouse is unresponsive, the attackers hide the cursor by manipulating the CSS property cursor.

The page also uses the following code to handle keystrokes:

After deobfuscation, we obtain a very small script:

It was probably assumed that running this code would result in the Escape (keycode=27), Ctrl (keycode=17), Alt (keycode=18) and Tab (keycode=9) keystrokes being ignored, as well as F1, F3, F4, F5 and F12. This could prevent the user from leaving the page using various keyboard shortcuts, but the trick does not work in modern browsers.

Another interesting detail is the animation of the supposed file encryption process, which is shown in the screenshots below. It consists of an endless succession of random numbers and letters, simulating enumeration of allegedly encrypted files in the system directory.

Page addresses

Cybercriminals often use alphanumeric domain names, where the number sequence corresponds to a date close to the domain registration date and the letter sequence is an abbreviation, for example, “mpa” (the Russian abbreviation for “municipal legal act”) or “kad” (“cadastral office”). Example of a fraudulent domain: 0402mpa21[.]ru.

We also saw domain names composed of topic-based words, such as “police” or “mvd”. Cybercriminals use them to mimic the addresses of the legitimate sites of law enforcement agencies. An example of such a domain is mvd-ru[.]tech.

Mobile version of fake MVD websites

The threat also exists on mobile devices. To determine the type of device during propagation, the User-Agent field in the header of the HTTP request is checked. As in the case of the “full” version, the victim is accused of breaking the law and ordered to pay a fine; the amount, however, is smaller than in the desktop version.

Family #2. Fake law enforcement websites in the Middle East: “Give us your card details”

The second family differs in the way that money is transferred to the ransomwarers. As before, the user is accused of violating the law, informed that their computer has been locked, and instructed to pay a fine. However, instead of leaving their account or telephone number for payment, the cybercriminals insert a data entry form on the page asking for card details.

This family of lockers is targeted mostly at users in the Middle East (UAE, Oman, Kuwait, Qatar, and Saudi Arabia). In addition, we have seen fraudulent pages disguised as Indian and Singaporean law enforcement websites. European equivalents are slightly less common.

In Q4 2020, this family threatened more than 130,000 users.

Examples of ransomware pages

Technical details

From a technical viewpoint, browser lockers of the second type are in many ways similar to the fake MVD websites. As in the first case, the content expands to full screen to make it difficult for the user to access the browser window controls and taskbar. At the top of the page is an address bar with the URL of the official government resource, and at the bottom is a fake taskbar with the Google Chrome icon. The mouse pointer is not displayed, and a script similar to the one above is used to handle keystrokes. Besides entering payment data, no actions on the page are available to the user.

The screenshot below shows an obfuscated script that implements the “locking,” as well as collects and sends the user-input data.

The victim’s payment details are transferred via an HTTP POST request to the same malicious resource that hosts the page. In the screenshot below is an example of a request to send payment details to the malicious site sslwebtraffic[.]cf.

Conclusion

The threats investigated are not technically complex. Their functionality is rather primitive and aims to create the illusion of locking the computer and intimidate the victim. Landing on such a page by mistake will not harm the user’s device or data, as long as they do not fall for the cybercriminals’ smoke-and-mirror tactics. What’s more, to get rid of the locker requires no special knowledge or technical means.

But if the user panics, they could lose money. Kaspersky solutions block malicious web resources and threat-related files (scripts, content elements) with the verdict HEUR:Trojan.Script.Generic.

Indicators of compromise

Fake MVD websites

2301tiz21[.]ru
112aubid[.]ru
00210kad[.]ru
1910mpa20[.]ru
mvd[.]pp[.]ru
mvd[.]net[.]ru
police-online[.]info
mvd-online-police[.]ga

Fake law enforcement websites in other countries

supportpayprogramarabicssn[.]ga
tkkmobileinternetssnstop[.]ml
tkkmobileinternetssnstopopen[.]gq
amende-police-4412[.]xyz
gropirworldplssn[.]ga

Financial Cyberthreats in 2020

31 Březen, 2021 - 16:00

2020 was challenging for everyone: companies, regulators, individuals. Due to the limitations imposed by the epidemiological situation, particular categories of users and businesses were increasingly targeted by cybercriminals. While we were adjusting to remote work and the rest of the new conditions, so were scammers. As a result, 2020 was extremely eventful in terms of digital threats, in particular those faced by financial institutions.

At the same time, some of the known APT (Advanced persistent threats) groups that are not generally targeting financial institutions have tried their hand at it. Existing at a special crossroads between APT and financial crime, the Lazarus group has already been among the most active ones in the financial sphere. In 2020, the group tried its hand at the big extortion game with the VHD ransomware family. Later on other groups, such as MuddyWater, followed suit.

Moreover, in 2020, we saw regional actors go global. A few Brazilian malware families expanded their operations to other continents, targeting victims in Europe and Asia. We have dubbed the first four families to have done this (Guildma, Javali, Melcoz, Grandoreiro) “the Tétrade”. Later on the authors of Guildma also created the new banking malware Ghimob targeting users located in Brazil, Paraguay, Peru, Portugal, Germany, Angola, and Mozambique.

Of course, the known financial threats have remained, too. Thus, the year 2020 saw a surge in the use of Emotet, described by Interpol as “the world’s most dangerous malware”. In the beginning of 2021, law enforcement agencies all over the world joined their forces to disrupt the botnet’s infrastructure. According to Kaspersky experts, the operation will frustrate Emotet’s activities for at least several months. In the meantime, at least some of Emotet customers have switched to Trickbot.

Even though, in 2020, we have seen ever more sophisticated cyberattacks, the overall statistics look encouraging: the number of users hit by computer and mobile malware declines, so does financial phishing. Still, that does not mean that the cyber world has become a safer place – it means that the cybercriminals’ goals and tactics have undergone a number of changes. Despite the decreasing general statistics, we see that attacks have become more targeted and business-oriented. At the same time, we observe cybercriminals to skillfully adapt themselves to the global changes and benefit from the teleworking vulnerabilities and the rising popularity of online shopping. This report aims to shed a light on more details of financial cyberthreats in 2020.

This research is a continuation of our annual financial threat reports (2019, 2018 and 2017) providing an overview of the latest trends and key events across the financial threat landscape. Traditionally, the study covers the common phishing threats encountered by users, along with Windows and Android-based financial malware.

Methodology

In this research, by financial malware we mean several types of malevolent software. Firstly, we identify as financial the malware targeting users of financial services such as online banking, payment systems, e-money services, e-shops, and cryptocurrency services. Secondly, we use the term to define the malware attempting to gain access to financial organizations and their infrastructure. In most cases, financial malware attacks rely on spamming and phishing activities, such as creating and distributing fake finance themed web pages and emails to steal the victims’ payment info.

To examine the financial sector threat landscape, Kaspersky researchers have analyzed the malicious activities on devices owned by individuals using the Kaspersky security products, which they volunteered to make available to us through the Kaspersky Security Network. The corporate user statistics were collected from the enterprise security solutions, after our customers agreed to share their data with Kaspersky.

The data for 2020 was mostly compared against 2019 to monitor the malware development trends. However, in some parts, for better insight into the financial malware evolution, the study also refers to earlier times.

Key findings

Phishing:

  • In 2020, the percentage of users hit by phishing declined slightly from 15.7% to 13.2%.
  • This time around, e-shops became the target of choice for phishing attacks. Almost every fifth attempted visit to a phishing page blocked by Kaspersky products has been related to online store phishing.
  • Phishing attacks against PayPal users soared from 26.8% in 2019 to 38.7% in 2020. The longtime leader of the category, Visa, dropped to the fourth place with 10.2% of phishing attacks against users of payment systems successfully prevented by Kaspersky in 2020.

PC:

  • In 2020, 625,364 users were attacked by banking Trojans – 148,579 less from 773,943 in 2019.
  • This year, users in Russia, Germany and Kazakhstan were the most frequent targets of financial malware.
  • Zbot is still the most widespread banking malware (22.2 % of attacked users), the second place is now held by CliptoShuffler (15.3%), with Emotet (14.5%) in the third place as before.
  • 36% of users hit by banking malware are corporate ones – an increase of one percentage point from the previous year.

Mobile:

  • This year, the number of users attacked by Android banking malware rapidly dropped by more than 55%: from 675,772 in 2019 to 294,158 in 2020.
  • Japan, Taiwan and Spain ended up with the highest percentage of users hit by Android banking malware.
Financial phishing

Financial phishing is one of the most popular tools used by cybercriminals to make money. Its prevalence is explained by the fact that it does not require much investment or technical expertise. In most cases, successful scammers win access either to the victim’s money or data that can be sold or otherwise monetized.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of financial phishing attacks (of the overall phishing attacks) detected by Kaspersky, 2016 – 2020 (download)

In 2020, Kaspersky anti-phishing technologies detected 434,898,635 attempted visits to various types of phishing pages. As can be seen from the graph above, 37.2% of those were related to financial phishing – 14.2 p.p. less than the figure registered in 2019 (51.4%). The lowest financial phishing percentage in the past five years.

By “financial phishing” we mean not banking phishing alone but several other types as well. For one, there are the ‘payment systems’, which include pages mimicking the well-known payment brands like PayPal, Visa, MasterCard, American Express and others. There are also the ‘e-shops’ which include online stores and auction sites like Amazon, Apple store, Steam, E-bay and others.

In 2019, the financial phishing cases detected by Kaspersky products were distributed as follows:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of financial phishing cases by type in 2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of financial phishing cases by type in 2020 (download)

The year 2020 was definitely a unique one when it comes to financial phishing. One year back, we reported an increase in bank-related phishing from less than 22% to almost 30%. In 2020, banking phishing reached only 10.72 percent of the total. The e-shops, with 7.57% in 2019, on the contrary, almost tripled reaching 18.12%. Kaspersky experts connect these changes with the lockdown measures due to the pandemic – at home most of the time, people turned to online shopping and digital entertainment. Thus, growing demand from the users has led to increased “supply” from the cybercriminals. It should be noted that, while online shopping proved the most appealing field for scammers, payment systems were not that much of a lure – their share barely reaching 8.41%.

2019 statistics on payment systems:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The most frequently used brands in ‘payment systems’ financial phishing schemes in 2019 (download)

As can be observed from the graph above, the users of Visa Inc. (37.6%) were targeted the most in 2019. PayPal came in second with 26.8%, while MasterCard closed the top 3.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The most frequently used brands in ‘payment systems’ financial phishing schemes in 2020 (download)

In 2020, the PayPal brand name (38.7%) was used for scam more than those of any other popular payment system. Its share grew by 12 p.p.

Example of a phishing page targeting PayPal users

Mastercard made it to the second place slightly increasing its share from 16.3% to 17.5%. The third and the fourth places, with a tiny difference between them, were taken by American Express (10.6%) and Visa (10.2%). As was observed, in 2020, scammers mimicked Visa Inc. 3.5 times less than in 2019 (37.6%).

Example of a phishing page targeting Visa users

In 2019, we analyzed the ‘e- shop’ brands most frequently used by cybercriminals in financial phishing schemes. The results showed Apple (42.8%) to be the number one choice for scam. The online stores Amazon (23.6%) and eBay (14.2%) took the second and the third place respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Brands most frequently used in ‘e-shop’ financial phishing schemes, 2019 (download)

Examples of phishing pages based on the online store brands most used by cybercriminals

In 2020, as the e-shop phishing continued to grow, Amazon made it to the first place with 27.84% of total. Challenged by the popular online store, Apple (27.07%) stepped down to the second place, its share reduced by 15 p.p. Steam and eBay swapped their positions – Steam (14.90%) finished third, and eBay (12.85%) fourth.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Brands most frequently used in ‘e-shop’ financial phishing schemes, 2020 (download)

Banking malware for PC

In this study, we analyze the banking malware that steals the credentials used to access online banking or payment system accounts and to intercept one-time passwords.

After an upsurge of malware activity in October 2016, when as many as 1,494,236 users were hit, we observed a gradual decline in the number of users attacked with banking malware. 2020 was no exception. The number of attacked users has declined from 773,943 in 2019 to 625,364 – almost a 20% drop.

The reduction can be explained by the fact that attacks are becoming more targeted – cybercriminals now prefer to attack large businesses. Yet common users and small entities continue to fall victim to cybercriminal groups such as Zbot, CliptoShuffler, Emotet, RTM and others.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Dynamic change in the number of unique users attacked with banking malware 2018 – 2020 (download)

The main actors

Every year we detect multiple families of banking malware: some of them become outdated, some, on the contrary, gain popularity among cybercriminals. Below is a list of top 10 most active banking malware families detected in 2019. The leading ones were Zbot (21.6%), RTM (19.8%), Emotet (12.6%), CliptoShuffler (5.6%) and Trickster (5.5%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 most widespread banking malware families in 2019 (download)

This year we continued tracking the most active banking malware families. It is quite noteworthy that only four of them (Zbot, CliptoShuffler, Emotet and RTM) account for more than one half of the attacked users. Below is a list of top 10 banking malware families we detected in 2020.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 most widespread banking malware families in 2020 (download)

While Zbot (22.2%) still enjoys the status of the most used malware in the financial sphere, there were some changes in the list. RTM, with 10.5%, dropped from the second to the fourth place, while two other families, CliptoShuffler (15.3%) and Emotet (14.5%), both climbed higher in 2020. Notably, Gozi (3.3%), the second most active family just two years ago, was pushed out to the ninth place.

What is more, year 2020 has also been special for expansion of regional threat actors into the outside world. Thus, the four large Brazilian families we have called the Tétrade went global targeting not only Latin America but Asian and European countries as well.

Geography of attacked users

To assess and compare the degree of computer infection risk faced by users in different countries of the world, we have calculated for each country the proportion of Kaspersky product users faced by the threat during the period of report versus the total number of users attacked by financial malware.

Traditionally, more than half of all users hit with banking malware in 2019 and 2020 came from 10 countries. In 2019, the top 10 was as follows:

Russian Federation 33.6% Germany 7.4% China 3.3% Brazil 3% India 3% Mexico 3% Vietnam 2.70% Italy 2.60% Kazakhstan 2% United States 2%

In 2019, Russia’s share reached 33.6% of the total, Germany finishing second with 7.4%, and China closing the top three with 3.3%.

In 2020, the situation was as follows:

Russian Federation 26.6% Germany 4.5% Kazakhstan 4.1% Brazil 3.4% China 3.4% Italy 3.3% India 3.1% Mexico 2.8% Vietnam 2.8% Uzbekistan 2.3%

As can be seen from the chart, despite the decline Russia (26.6%) and Germany (4.5%) still hold the first and second places in the top 10. Notably, Russia’s figures always tend to be the highest due to the fact that most Kaspersky users are located in Russia. Kazakhstan, which used to be 9th with 2%, this year broke into the top three having added 2 more percentage points.

Types of users attacked

It can be noticed that financial malware becomes more corporate-oriented. This year we observed that 36% of users attacked by banking malware are corporate ones – one percentage point up from the previous year. This partly confirms our hypothesis about cybercriminals shifting their attention to the corporate sector. Still, the increase is relatively small, and we expect the redistribution of attacks between corporate and private users to clear up in the near future.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Corporate vs consumer product users, 2019–2020 (download)

All in all, in 2020, companies became more vulnerable due to the restrictions for onsite work and staff, coupled with increased number of employees using the corporate network remotely. The hasty transition to teleworking has affected the corporate security – most businesses were not ready to go online. Some of them lacked the devices, so employees had to use their home computers for work. Lack of online security training, default laptop configurations left as is, vulnerable remote access connections – together these factors have paved way to all sorts of attacks, including banking malware scams.

Сryptocurrency related cyberthreats in 2020

Three years ago, in 2018, cryptocurrencies made the hottest topic and turned the eyes of the whole cybersecurity community to the new danger. We have analyzed the hidden mining software cybercriminals spread to coin money at the users’ cost, and found that today the malicious activity is not that widespread.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mining malware in 2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mining malware in 2020 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Geography of mining attacks, 2020 (download)

Thus, in 2020, we continued to observe a downward trend for this type of threat. Yet by the end of the year the numbers reached a certain plateau, and we even saw local trend reversals. It is likely that the sharp increase in cryptocurrency prices at the end of 2020 may boost the threat in early 2021. Moreover, due to the COVID crisis, we may yet see some economies collapsing and local currencies plummeting in 2021, which would turn cryptomining a lot more attractive.

Mobile banking malware

Android banking malware is a well-known threat Kaspersky experts have been analyzing for years. Last year was a dramatic one in terms of mobile banking malware. As stated in our previous annual report, in 2019, the number of users hit by it dropped to just over 675 thousand from around 1.8 million in 2018.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked with Android banking malware, 2018 – 2019 (download)

In 2020, we observed a continuation of this trend as the number of attacked users decreased by more than 55% to 294,158.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked with Android banking malware, 2019 – 2020 (download)

To get a better view of the reasons behind these dramatic changes, Kaspersky experts took a closer look at the landscape and reviewed the most widespread families over the year. In 2019, the situation was as follows:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Most widespread Android banking malware in 2019 (download)

In 2020, Asacub’s (25.6%) share is still the weightiest. Yet it shrank by 18.8 percentage points since 2019. Agent (18.0%) is still in the second position, although a bit lighter from the year before. Svpeng (12.8%), which mostly hunts for the administrator rights on the infected device, this year was challenged by Rotexy (17.9%), in which the banking Trojan’s features are combined with those of a ransomware blocker.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Most widespread Android banking malware in 2020 (download)

All in all, 2020 was rich in new mobile banking malware. Let us give a brief overview of this year’s major findings:

  • Trojan-Banker.AndroidOS.Ghimob.a
    New banking malware from the Tétrade group that went global this year and attacked banks, exchanges, cryptocurrency exchangers and fintech organizations in Brazil, Paraguay, Peru, Portugal, Germany, Angola, and Mozambique. Ghimob was able to spy on a total of 153 mobile apps, which is impressive for a banking Trojan.
  • Trojan-Banker.AndroidOS.Gorgona.a
    The malware mimics Google Play and uses the notification panel to attract the user’s attention. It can make and redirect calls, execute USSD commands, install additional apps and block the device, if needed. If granted the permission to use Accessibility, it can get even more rights, for example, to receive and process text messages. Thus, it can gain control of the two-factor authentication. Uses TCP for C2 communication. Tends to target banks in Turkey.
  • Trojan-Banker.AndroidOS.Knobot.a
    The new financial threat market player. Alongside phishing windows and interception of the two-factor authentication messages, the Trojan offers several features not typical of financial threats. For example, a mechanism for interception of device PIN code through Accessibility services.
    Ironically, it asks its victim to delegate the rights and even provides a small instruction on how to do it.

    A screenshot of Trojan-Banker.AndroidOS.Knobot.a on user’s phone

Geography of attacked users

Top 10 countries by percentage of users hit by Android banking malware in 2019:

Russian Federation 0.72% South Africa 0.66% Australia 0.59% Spain 0.29% Tajikistan 0.21% Turkey 0.20% United States 0.18% Italy 0.17% Ukraine 0.17% Armenia 0.16%

Top 10 countries by percentage of users hit by Android banking malware in 2020:

Japan 2.83% Taiwan (province of China) 0.87% Spain 0.77% Italy 0.71% Turkey 0.60% Korea 0.34% Russian Federation 0.25% Tajikistan 0.21% Poland 0.17% Australia 0.15%

As can be seen from the statistics, all the countries were completely reshuffled year on year. Russia from it top position in 2019 moved to the 7th place in 2020. Armenia, which used to close the 2019 chart, left it altogether. On the other hand, Japan (2.83%) and Taiwan (0.87%), not even mentioned in 2019, rapidly gained more users hit by Android banking malware and made it to the top. Meanwhile Spain (0.77%) ousted Australia from the third place with almost 3 thousand of affected users.

Conclusion

The year 2020 has shown that cybercriminals can easily adapt to new realities of the changing world. They keep updating their malware with new features and improving the detection avoidance techniques. The general statistics in all the areas we have analyzed (PC and mobile malware, phishing) is on the downward trend, which is a good sign.

We have observed that, in 2020, the phishing scammers have switched their attention from banks to e-shops. This trend is closely related to the pandemic, which has greatly changed the public’s attitude towards online shopping: criminals have marked its growing popularity and turned focus on it. We have registered a slight increase of the share of malware attacks against corporate users. The emerging trend of banking Trojans targeting corporate users is also of concern, as such attacks are likely to bring more problems than attacks on individuals. At the same time, the regional scam factories targeting financial organizations are increasingly reaching the global level, potentially resulting in more growth in 2021. Thus, even though the general statistics look positive, we have to consider the massive threat landscape still faced by financial organizations.

For protection against financial threats, Kaspersky recommends users to:

  • Install only applications obtained from reliable sources, such as the official websites;
  • Check the access rights and permissions requested by the application – do not grant them if they fail to match the app’s feature set;
  • Never follow links from spam messages and never open documents attached to them;
  • Install a trusted security solution, such as Kaspersky Security Cloud – it will protect you from a broad range of financial cyberthreats.

To protect your business from financial malware, Kaspersky security experts recommend:

  • Introduce cybersecurity awareness training for your employees, particularly those responsible for accounting, to teach them to detect phishing pages and improve the digital literacy of staff in general;
  • For critical user profiles, such as those in financial departments, enable the default deny mode for web resources to ensure that only legitimate ones can be accessed;
  • Install the latest updates and patches for all the software you use;
  • For protection from complex threat and targeted attacks, install the anti-APT and EDR solutions for network threat detection, incident investigation and timely recovery action. Provide your SOC team with access to the latest threat intelligence and regular upskill training. All these are available within the Kaspersky Expert Security framework.

APT10: sophisticated multi-layered loader Ecipekac discovered in A41APT campaign

30 Březen, 2021 - 12:00

Why is the campaign called A41APT?

In 2019, we observed an APT campaign targeting multiple industries, including the Japanese manufacturing industry and its overseas operations, that was designed to steal information. We named the campaign A41APT (not APT41) which is derived from the host name “DESKTOP-A41UVJV” from the attacker’s system used in the initial infection. The actor leveraged vulnerabilities in Pulse Connect Secure in order to hijack VPN sessions, or took advantage of system credentials that were stolen in previous operations.

Log of the hijacking VPN session from DESKTOP-A41UVJV

A41APT is a long-running campaign with activities detected from March 2019 to the end of December 2020. Most of the discovered malware families are fileless malware and they have not been seen before. One particular piece of malware from this campaign is called Ecipekac (a.k.a DESLoader, SigLoader, and HEAVYHAND). It is a very sophisticated multi-layer loader module used to deliver payloads such as SodaMaster (a.k.a DelfsCake, dfls, and DARKTOWN), P8RAT (a.k.a GreetCake, and HEAVYPOT) and FYAnti (a.k.a DILLJUICE stage2) which loads QuasarRAT.

In November and December 2020, Symantec and LAC both published blogposts about this campaign. A month later, we discovered new activities from A41APT that utilized modified and updated payloads, and that’s what we cover in this blog.

In February 2021, a GReAT security expert and his friends gave a presentation on the A41APT campaign at the GReAT Ideas event. You can download the slides here. Further information about A41APT is available to customers of the Kaspersky Intelligence Reporting service. Contact intelreports@kaspersky.com

Technical analysis: Ecipekac

We observed a multi-layer x64 loader used exclusively by this actor and dubbed Ecipekac after a unique string found in the second layer of the Ecipekac loader. The string is “Cake piece” in reverse (with a typo).

The hardcoded unique string “ecipekac”

Ecipekac uses a new, complicated loading schema: it uses the four files listed below to load and decrypt four fileless loader modules one after the other to eventually load the final payload in memory.

Ecipekac infection flow

The files are:

Filename MD5 Hash Description policytool.exe 7e2b9e1f651fa5454d45b974d00512fb Legitimate exe for DLL side-loading jli.dll be53764063bb1d054d78f2bf08fb90f3 Ecipekac Layer I loader vac.dll f60f7a1736840a6149d478b23611d561 Encrypted Ecipekac Layer II loader (shellcode) pcasvc.dll 59747955a8874ff74ce415e56d8beb9c Encrypted Ecipekac Layer IV loader (shellcode)

Please note that the Ecipekac Layer III loader module is embedded in the encrypted Layer II loader.

Ecipekac: Layer I loader

Layer I of Ecipekac infection flow

The Ecipekac Layer I loader abuses policytool.exe, a legitimate application that is normally packaged in the IBM Development Package for Eclipse, to load a malicious DLL named ‘jli.dll’ in the current directory via the DLL side-loading technique. The ‘jli.dll’ file acts as the first layer of the Ecipekac loader. This DLL file has a number of export functions; however, all of them refer to a similar function that carries the main loading feature. The loader reads 0x40408 bytes of data from the end of another DLL – ‘vac.dll’ (where the data section starts at the offset of 0x66240). The data size of 0x40408 is derived from a hardcoded value, 0x40405, incremented until it’s divisible by eight.

MD5 f60f7a1736840a6149d478b23611d561 SHA1 5eb69114b2405a6ea0780b627cd68b86954a596b SHA256 3b8ce709fc2cee5e7c037a242ac8c84e2e00bd597711093d7c0e85ec68e14a4c Link time 2033-11-13 08:50:03 File type PE32+ executable (DLL) (GUI) x86-64, for MS Windows Compiler Linker Version: 14.13, OS Version: 10.0 File size 681544 (666KB) File name vac.dll Embedded data at 0x66240
(size:0x40405)
00066240: febe d990 66de 1bc9 75b7 dc2c 3e1f 3ef2
00066250: 78d0 0005 5c27 a511 c122 bdf4 15e7 052c
00066260: af72 7e08 064c f7b9 70f0 57bf 250a 3b4d
[..skipped..]  
000a6630: ee4b b1f2 294d eea1 290e aba2 6954 130f
000a6640: 1267 9ab3 f800 0000

The ‘vac.dll’ DLL file is signed with a valid, legitimate digital signature, although the file has been tampered with. At first glance, the fact that its digital signature is valid would suggest the file has not been manipulated after being digitally signed.

The signed digital certificate of vac.dll

However, what happened was that the actor resized the Certificate Table in the digitally signed ‘vac.dll’ and inserted their own data in the Certificate Table so it doesn’t affect the digital signature. This technique was published at BlackHat 2016 as MS13-098.

The layer I loader decrypts the layer II loader shellcode from the embedded data in ‘vac.dll’. Several crypto algorithms are used, such as XOR, AES and DES. The order and combination of algorithms, as well as the decryption keys, are different from one sample to another.

Decryption flow in first loader

For example, in the sample shown above, the order of crypto algorithms was a one-byte XOR using the hardcoded key of ‘0x9F’, followed by an AES CBC mode decryption with the AES key ’83H4uREKfFClDH8ziYTH8xsBYa32p3wl’ and the IV key ’83H4uREKfFClDH8z’.

One interesting characteristic of Ecipekac is that the attackers implemented these cryptographic algorithms in their own code instead of using the Windows API. The attackers have also made slight modifications compared to the original implementation. For instance, in the function related to the AES algorithm, they intentionally referenced the third byte of the AES key as shown in the following code.

A small modification in the AES function

Apart from the AES algorithm mentioned, the attackers have also modified the DES algorithm.

Ecipekac: Layer II loader shellcode

Layer II of infection flow using Ecipekac

The Ecipekac Layer II loader is a simple shellcode which contains the data of the next layer DLL in disordered parts. At first, this shellcode checks for the magic string “ecipekac” in this data set. Then it reconstructs and loads each part of the embedded data into allocated memory in the correct order to create the original code of the DLL as shown below.

Reconstruction for the divided PE BLOB in memory

Then it calls the entry point of the loaded DLL which is the third layer of Ecipekac. Based on our investigation, the magic string used in this module is not exclusively “ecipekac” in all instances. We also observed “9F 8F 7F 6F” and “BF AF BF AF” being used in several samples instead.

Ecipekac Layer III loader DLL

Layer III of infection flow using Ecipekac

The third layer’s method of loading the next layer resembles the first layer. It reads encrypted data from the end of ‘pcasvc.dll’, which is signed using a digital certificate as is the case with ‘vac.dll’.

MD5 59747955a8874ff74ce415e56d8beb9c SHA1 0543bfebff937039e304146c23bbde7693a67f4e SHA256 a04849da674bc8153348301d2ff1103a7537ed2ee55a1588350ededa43ff09f6 Link time 2017-02-24 15:47:04 File type PE32+ executable (DLL) (console) x86-64, for MS Windows Compiler Linker Version: 14.13, OS Version: 10.0 File size 733232 (717KB) File name pcasvc.dll Embedded data at 0x87408 (size:0x2BC28) 00087408: 98e4 1def 8519 d194 3c70 4e84 458a e34c
00087418: b145 74da c353 8cf8 1d70 d024 8a54 8bde
[..skipped..]  
000b3010: 2c1b 6736 8935 d55d 8090 0829 5dfc 7352
000b3020: 44bd c35b 9b23 1cb6 0000 0000 0000 0000

The crypto algorithms are again one-byte XOR and AES CBC mode, this time to decrypt the fourth loader shellcode from the embedded data of ‘pcasvc.dll’. However, the sequence of algorithms is in reverse order compared to the first layer. The hardcoded keys are also different: “0x5E” is used as the XOR key, while the AES key and IV are “K4jcj02QSLWp8lK9gMK9h7W0L9iB2eEW” and “K4jcj02QSLWp8lK9” respectively.

Ecipekac: Layer IV loader shellcode

Layer IV of infection flow using Ecipekac

During our research, we found three different types of shellcode used as the fourth layer of Ecipekac.

Layer IV loader shellcode – first type

The first shellcode type’s procedure acts the same way as the Ecipekac Layer II shellcode, with the only difference being the embedded PE, which is the final payload of Ecipekac in this case. The payload of the first type shellcode is either “P8RAT” or “FYAnti loader”. An analysis of these payloads is provided in the later sections of this report.

Layer IV loader shellcode – second type

The second type of shellcode is totally different from the other loader types. This shellcode has a unique data structure shown in the table below.

Offset Example Data Description 0x000 90 90 90 90 90 90 90 90 magic number to check before proceeding to data processing. 0x008 0x11600 size of encrypted data 0x00C A9 5B 7B 84 9C CB CF E8 B6 79 F1 9F 05 B6 2B FE 16 bytes RC4 key 0x01C C7 36 7E 93 D3 07 1E 86 23 75 10 49 C8 AD 01 9F 6E D0 9F 06 85 97 B2
[skipped] Encrypted payload (SodaMaster) by RC4

This shellcode confirms the presence of the magic number “90 90 90 90 90 90 90 90” at the beginning of this data structure, before proceeding to decrypt a payload at offset 0x01C using RC4 with a 16-byte key of “A9 5B 7B 84 9C CB CF E8 B6 79 F1 9F 05 B6 2B FE”. The decrypted payload is “SodaMaster”, and is described later in this report.

Layer IV loader shellcode – third type

The last type of shellcode is a Cobalt Strike stager. We have confirmed the use of several different Cobalt Strike stager shellcodes since October 2019. In addition, some of the observed Cobalt Strike stager samples included a setting in the HTTP header of their malicious communications to disguise them as common jQuery request in order to evade detection by security products.

Hardcoded HTTP header to impersonate jQuery request

The actual hardcoded C2 used in the HTTP header for the C2 communication impersonating JQuery requests was “51.89.88[.]126” with the respective port 443.

Payloads of Ecipekac

Payload of Infection flow using Ecipekac

As mentioned previously, apart from the Cobalt Strike stager, we observed three types of final payload implanted by the Ecipekac loader during this long-running campaign.

  • P8RAT
  • SodaMaster
  • FYAnti loader for QuasarRAT

The following timeline shows samples of the Ecipekac loader together with their respective filename and payload type based on a compilation timestamp of the first layer DLL:

Timeline of the Ecipekac loader files and payloads

Cobalt Strike’s stager has been used throughout the research period. FYAntiLoader for QuasarRAT was monitored in October 2019, and has not been observed since then. Instead of this, SodaMaster and P8RAT were monitored from May 2020.

P8RAT

One of Ecipekac’s payloads is a new fileless malware which we call P8RAT (a.k.a GreetCake). P8RAT has the following unique data structure used to store the C2 communication configuration. We collected several samples of P8RAT during our research and found no C2 address of P8RAT that was used more than once. In total we found 10 backdoor commands in all the collected P8RAT samples. The most recent P8RAT sample, with the compilation timestamp of December 14, 2020, shows a new backdoor command with the code number of “309” implemented. The command “304”, which was present in earlier samples and carries similar functionality, was removed.

Command Description Compilation time of P8RAT 2020-03-30 2020-08-26 2020-12-14 300 Closing socket Enabled Enabled Enabled 301 Creating a thread for executing/loading a downloaded PE file Enabled Enabled Enabled 302 No functionality Enabled Removed Removed 303 Sending randomly generated data Enabled Enabled Enabled 304 Executing/loading downloaded PE/shellcode Enabled Removed Removed 305 Setting value of “Set Online Time” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 306 Setting value of “Set Reconnect TimeOut” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 307 Setting value of “Set Reconnect times” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 308 Setting value of “Set Sleep time” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 309 Creating thread for executing downloaded shellcode was implemented from the P8RAT version compiled on 2020-12-14. Not implemented Not implemented Enabled

The main purpose of P8RAT is downloading and executing payloads (consisting of PE and shellcode) from its C2 server. However, we were unable to obtain any sample of the subsequent payloads for this malware.

In the P8RAT sample from March 2020, hardcoded strings such as “Set Online Time”, “Set Reconnect TimeOut”, “Set Reconnect Times” and “Set Sleep Time” were used in regard to backdoor commands “305” to “308”, which point to the possible purpose of these commands. Based on these strings, which were removed from the P8RAT samples in August 2020, we speculate that these commands are possibly used to control the intervals of the C2 communication by defining sleep time, reconnect time and reconnect timeout in order to blend C2 communication with normal network traffic of the system.

In another update, the P8RAT sample from August 2020 looks for two process names (“VBoxService.exe” and “vmtoolsd.exe”) on the victim’s system, to detect VMware or VirtualBox environments at the beginning of its main malicious function.

Hardcoded file names to detect VMware and VirtualBox

Interestingly the attacker made some modifications to P8RAT in December 2020, shortly after the publication of the two blogposts from Symantec on November 17, 2020, and LAC on December 1, 2020 (in Japanese). We strongly believe that this actor had examined these security vendors’ publications carefully and then modified P8RAT accordingly.

SodaMaster

Another payload of the Ecipekac loader, which we call SodaMaster (a.k.a DelfsCake), is also a new fileless malware. In our research we found more than 10 samples of SodaMaster. All the collected samples of this module were almost identical, with the offsets and hex patterns of all functions perfectly matching. The only differences were in the configuration data, including a hardcoded C2, an encoded RSA key and additional data for calculating a mutex value.

Configuration of SodaMaster

When execution of this malware begins, it creates a mutex with a name in the reverse order of the CRC32 checksum calculated from the encoded RSA key and its following additional data. Then the malware randomly generates a value as an RC4 key for C2 communication. The first data block sent to the C2 server includes the user_name, the host_name, PID of the malware module, OS_version, socket_name, the generated RC4 key and the malware’s elapsed running time.

C2 communication of SodaMaster

We confirmed four backdoor commands, coded as “d”, “f”, “l” and “s”, in the recent SodaMaster sample. In addition, we also discovered an old SodaMaster sample which has only two commands. A description of each command is shown in the following table.

Command Description Compilation time of SodaMaster 2019-01-07 2019-06-10 d Create thread for launching downloaded DLL and call export function of the DLL. Enabled Enabled f Set value as RC4 key for the encrypted C2 communication Not implemented Enabled l Set value as sleep time Not implemented Enabled s Create thread for executing downloaded shellcode Enabled Enabled

Based on the analysis of the backdoor features of the SodaMaster module, the purpose of this malware is also to download and execute payloads (DLL or shellcode), like P8RAT. Unfortunately, we have not been able to obtain these payloads yet.

The SodaMaster module also shows an anti-VM feature. The malware looks for the presence of the registry key “HKEY_CLASSES_ROOT\\Applications\\VMwareHostOpen.exe” on the victim’s system before proceeding to its main functionality. This registry key is specific to the VMware environment.

SodaMaster anti-VM check

Another characteristic of SodaMaster is the use of a common obfuscation technique known as “stackstrings” to create the registry key in double-byte characters. We observed the same obfuscation technique used for a process name and DLL name in other SodaMaster samples.

FYAnti loader for QuasarRAT

The last observed type of payload deployed by Ecipekac is a loader module named FYAnti loader. In the Ecipekac loader malware of the fourth layer, the DLL is loaded into memory and an export carrying the name “F**kY**Anti” is called. We named this loader “FYAnti” because of this distinct string. The execution flow of the FYAnti has two additional layers to implement the final stage, which is a QuasarRAT (a.k.a xRAT).

Infection flow of FYAnti loader

The first layer of the FYAnti loader decrypts an embedded .NET module and executes it using the CppHostCLR technique. The .NET module is packed using “ConfuserEx v1.0.0” and acts as yet another loader that searches for a file in the “C:\Windows\Microsoft.NET\” directory with file sizes between 100,000 and 500,000. The unpacked code is shown in the screenshot below.

Unpacked code of the second layer loader of FYAnti to search a file

In this instance, an encrypted file named “web_lowtrust.config.uninnstall” is found and used as the next stage module. The .NET module loads and decrypts this file using AES CBC mode. The decrypted payload is another .NET module named Client.exe which is QuasarRAT, a popular open-source remote administration tool. The configuration data is stored in the binary with most of this data being encrypted by AES CFB mode and base64. The AES key is generated using the hardcoded string “KCYcz6PCYZ2VSiFyu2GU”in the configuration data.

Malware configuration of QuasarRAT

All loader modules and payloads are decrypted and executed in memory only.

Attribution

Based on our investigations, we assess with high confidence that the APT10 threat actor is behind the A41APT campaign. This attribution is based on the following points:

First, the hardcoded URL “www.rare-coisns[.]com” from an x86 SodaMaster sample was mentioned in the report from ADEO regarding APT10’s activity targeting the finance and telecommunication sectors of Turkey, also fitting the geolocation of the VirusTotal submitter.

Second, the similarity of the A41APT campaign with APT10 activities described in a Cylance blogpost. These include the Ecipekac Loader, FYAnti loader’s unique export name “F**kY**Anti”, using the CppHostCLR technique and QuasarRAT used as the FYAnti’s final payload. Moreover, as stated in the Symantec blogpost, the FYAnti loader, the export name “F**kY**Anti”, CppHostCLR technique for injection of .NET loader and the QuasarRAT were similar to the activities of the APT10 group discovered by the BlackBerry Cylance threat research team.

Last but not least, there are some similarities and common TTPs to those outlined in our previous TIP report on APT10 activities:

  • Implementation of the hashing or crypto algorithms done manually by the malware developers instead of using Windows APIs, with some modifications;
  • Use of calculated hash values (fully or partially) for some features like crypto keys, part of the crypto keys, key generation, mutex names and so on;
  • Using the DLL side-loading technique to run a payload in memory;
  • Using PowerShell scripts for persistence and also for lateral movement;
  • Using exe for removing logs in order to hide their activities;
  • Sending victim machine data such as username, hostname, PID, current time and other specifics – though this point is not unique to APT10 backdoors and is quite common in most backdoor families;
  • Modifying implants shortly after security researchers publish their analysis of the actor’s activities and TTPs;
  • Targeting mainly Japan, alongside associated overseas branches or organizations related to Japan.

However, we observed some interesting differences in the A41APT campaign and previous activities:

  • P8RAT and SodaMaster did not contain a malware version number as opposed to the previous malware instances used by APT10 such as LilimRAT, Lodeinfo and ANEL;
  • As for the infection vector, we could not identify any spear-phishing email in this A41APT campaign, which is quite common in APT10 attacks.

Overall, APT10 is considered a large APT group running multiple simultaneous campaigns and, understandably, TTPs differ from one campaign to another. We believe the differences mentioned here for the A41APT campaign represent a normal variation of TTPs that can be expected in the case of such a large APT group.

Conclusions

We consider the A41APT campaign to be one of APT10’s long-running activities. This campaign introduced a very sophisticated multi-layer malware named Ecipekac and its payloads, which include different unique fileless malware such as P8RAT and SodaMaster.

In our opinion, the most significant aspect of the Ecipekac malware is that, apart from the large number of layers, the encrypted shellcodes were being inserted into digitally signed DLLs without affecting the validity of the digital signature. When this technique is used, some security solutions cannot detect these implants. Judging from main features of the P8RAT and SodaMaster backdoors, we believe that these modules are downloaders responsible for downloading further malware that, unfortunately, we have not been able to obtain so far in our investigation.

We see the activity outlined in this report as a continuation of the activity we previously reported in our Threat Intelligence Portal, where, in 2019, this threat actor began targeting overseas offices of Japanese associations or organizations using the ANEL malware. The operations and implants of the campaign described in this report are remarkably stealthy, making it difficult to track the threat actor’s activities. The main stealth features are the fileless implants, obfuscation, anti-VM and removal of activity tracks.

We will continue to investigate and track the activities of the APT10 actor, which are expected to keep improving its covertness with each year.

Appendix I – Indicators of Compromise

Note: The indicators in this section are valid at the time of publication. Any future changes will be directly updated in the corresponding .ioc file.

File Hashes (malicious documents, trojans, emails, decoys)

Ecipekac loader
be53764063bb1d054d78f2bf08fb90f3   jli.dll     P8RAT
cca46fc64425364774e5d5db782ddf54   vmtools.dll SodaMaster
dd672da5d367fd291d936c8cc03b6467   CCFIPC64.DLL      FYAnti loader

Encrypted Ecipekac Layer II, IV loader (shellcode)
md5   filename    payloads
f60f7a1736840a6149d478b23611d561   vac.dll     P8RAT
59747955a8874ff74ce415e56d8beb9c   pcasvc.dll  P8RAT
4638220ec2c6bc1406b5725c2d35edc3    wiaky002_CNC1755D.dll   SodaMaster
d37964a9f7f56aad9433676a6df9bd19    c_apo_ipoib6x.dll SodaMaster
335ce825da93ed3fdd4470634845dfea   msftedit.prf.cco  FYAnti loader
f4c4644e6d248399a12e2c75cf9e4bdf   msdtcuiu.adi.wdb  FYAnti loader

Encrypted QuasarRAT
md5   filename    payloads
019619318e1e3a77f3071fb297b85cf3   web_lowtrust.config.uninstall QuasarRAT

Domains and IPs

151.236.30[.]223
193.235.207[.]59
45.138.157[.]83
88.198.101[.]58
www.rare-coisns[.]com

Appendix II – MITRE ATT&CK Mapping This table contains all the TTPs identified in the analysis of the activity described in this report. Tactic Technique Technique Name Initial Access T1133 External Remote Services

Uses vulnerabilities in Pulse Connect Secure to hijack a VPN session. T1078 Valid Accounts

Uses stolen credentials to connect to the enterprise network as initial infection. Execution T1059.001 Command and Scripting Interpreter: PowerShell

Uses PowerShell to download implants and remove logs. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. Persistence T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. Privilege Escalation T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. Defense Evasion T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. T1070.003 Indicator Removal on Host: Clear Command History

Removes Powershell execution logs using Wevtutil.exe. T1036 Masquerading

Encrypted shellcode of Ecipekac was embedded in the legitimate DLL. T1497.001 Virtualization/Sandbox Evasion: System Checks

Payloads of Ecipekac check a registry key and process names to identify VM environment. Discovery T1057 Process Discovery

Checks the process of VMware and VirtualBox to identify the VM environment. T1082 System Information Discovery

SodaMaster sends system information such as user_name, the host_name, PID of the malware module, OS_version, etc. T1012 Query Registry

Checks a registry key of VMware to identify the VM environment. Lateral Movement T1210 Exploitation of Remote Services

Uses vulnerabilities in Pulse Connect Secure to hijack a VPN session. Command and Control T1071.001 Application Layer Protocol: Web Protocols

Cobalt Strike’s stager uses HTTP protocol for communication with C2 server to disguise as a common jQuery. T1132.002 Data Encoding: Non-Standard Encoding

SodaMaster uses an original data structure and RSA for the first communication, then uses RC4 for encryption.

Doxing in the corporate sector

29 Březen, 2021 - 12:00

Introduction

Doxing refers to the collection of confidential information about a person without their consent for the purpose of inflicting harm on that person or to otherwise gain some benefit from gathering or disclosing such information. Normally, doxing involves a threat to specific people, such as media personalities or participants of online discussions. However, any organization can also become a victim of doxing. Confidential corporate information is no less sensitive than the personal data of an individual, and the sheer scale of financial and reputational risks from potential blackmail or disclosure of such information can have a colossal impact.

In the article titled “Dox, steal, reveal. Where does your personal data end up?”, we mentioned that a cybercriminal could attack their victim by using targeted phishing e-mails to obtain access to the victim’s data. But this probably would be an expensive undertaking. However, when doxing is aimed at the corporate sector, cybercriminals are less hindered by the cost of an attack because the potential monetary rewards are much larger. To gather as much confidential corporate information as possible, cybercriminals are employing much more diverse methods than they normally would in their attacks against individual users. We will discuss those methods in this article.

Collecting information about a company from public sources

The first and simplest step that can be taken by cybercriminals is to gather data from publicly accessible sources. The Internet can provide doxers with all kinds of helpful information, such as the names and positions of employees, including those who occupy key positions in the company. Such key positions include the CEO, HR department director, and chief accountant.

For example, if LinkedIn shows that the CEO of a company is “friends” with the chief accountant or head of the HR department, and these persons are also friends with their direct subordinates, a cybercriminal only needs to know their individual names to easily figure out the company’s hierarchy and use this information for subsequent attacks.

In less professionally-oriented social networks such as Facebook, many users indicate their workplace and also publish a large amount of personal information, including recreational photos and the specific restaurants and gyms that they visit. You might think that this kind of information would be useless for an attack on a company because this personal info is not actually related to the company and contains no data that could actually compromise the company or the account owner. However, you would be surprised at how useful this information really could be to a cybercriminal.

Attacks using publicly accessible data: BEC

Information from personal profiles of employees can actually be used to set up BEC attacks. A BEC (Business E-mail Compromise) is a targeted attack on the corporate sector in which a cybercriminal initiates e-mail correspondence with an employee of an organization by posing as a different employee (including their superior) or as a representative of a partner company. The attacker does this to gain the trust of the victim before ultimately persuading the victim to perform certain actions, such as sending confidential data or transferring funds to an account controlled by the attacker. We registered 1,646 unique BEC attacks during February of 2021 alone. Let’s examine a scenario in which information from personal profiles of employees can help cybercriminals achieve their ultimate goals.

On his own page on a social network, an employee of a large company publishes an innocent photo with an ocean view and a comment stating that he still has three more weeks of vacation. A few days later, the company account department’s mailbox receives an e-mail from the vacationing employee requesting his pay to be deposited to a card in a different bank. The e-mail sender requests that they take care of this as quickly as possible, and explains that he can’t take any calls because he got sick and is not able to speak over the phone.

Example BEC attack with switched bank details

The unsuspecting accountant asks the employee to send his new bank details. After receiving this new banking information, the accountant changes the employee’s data in the system, and payment is sent to the new bank account some time later. However, a few weeks later, the clueless employee returns from vacation without a penny to his name and is dying to know why the accountant never sent his money.

After a little investigation, they determine that the e-mail regarding payment had been sent by cybercriminals who found out from the employee’s social network post that he was on vacation and temporarily unreachable. Although they used the real first and last name of the employee, the fraudulent message had been sent from a spoofed domain that was very similar to the domain of the organization (more details about this technique can be found in this article).

BEC attacks as a means to collect data

In the example above, the goal of the cybercriminals was a one-time financial profit. However, as we mentioned earlier, BEC attacks can also be aimed at obtaining confidential information. Depending on the position of the employee or the importance of the partner being impersonated by the cybercriminals, they could obtain access to fairly sensitive documents such as contracts or customer databases. In addition, cybercriminals may not limit themselves to just one attack, but could use any acquired information to pursue a larger goal.

Leaked data

Confidential documents that end up in the public domain either by carelessness or from malicious intent can also help cybercriminals to complete a dossier on a company. Over the past few years, there has been a notable increase in data breaches related to data stored in the cloud. Most of these breaches occur with Amazon AWS Simple Cloud Storage (AWS S3) due to the widespread popularity of this system as well as the apparent simplicity of its configuration, which does not require any special knowledge of information security. This simplicity is what ultimately poses a danger to the owners of file repositories in AWS known as “buckets”, which are most often breached due to an incorrect system configuration. For example, in July of 2017, the data of 14 million Verizon users was breached due to incorrectly configured buckets.

Tracking pixel

Cybercriminals may resort to various technical tricks to obtain information relevant to their particular goals. One of these tricks is to distribute e-mail messages containing tracking pixel that are often disguised as some type of “test” messages. This technique enables attackers to obtain data such as the time the e-mail was opened, the specific version of the recipient’s mail client, and the IP address, which could help find out the approximate location of the recipient. Using this information, cybercriminals can build a profile on a specific person whom they can then impersonate in subsequent attacks. Specifically, if scammers know the daily schedule and time zone of an employee, they can choose the most ideal time to conduct an attack.

Here’s one example of doxing through the use of a tracking pixel, in which the CEO of a large company receives so-called “test messages” whose contents may slightly vary.

Example test message containing a tracking pixel

Messages arrive from different domains and at different times. Some come at the peak of the workday, and some come late at night. The latter are opened by the company CEO almost immediately after they arrive to work. Those “test messages” continue to arrive for approximately a week, and then abruptly stop. The CEO thinks the incident is some kind of joke and quickly forgets about it. However, it soon turns out that the company has transferred a few million dollars to the address of an outside company. An investigation reveals that someone claiming to be the CEO had sent several e-mails demanding that the company accountants immediately pay for services rendered by the outside company. This scenario matches one variant of a BEC attack known as a CEO fraud attack, in which cybercriminals pose as top managers of organizations.

Example e-mail used to initiate a CEO fraud attack

In this scenario, cybercriminals found out the work schedule of their targets by using “test messages” containing a tracking pixel that they sent not only to the CEO but also to specific accounting employees. They were then able to request the transfer of a large sum of money supposedly on behalf of the CEO at an ideal time when the CEO was unreachable, but the accounting department was already online.

Phishing

Despite their seemingly primitive simplicity, e-mail phishing and other malicious attacks still serve as some of the main tools used by cybercriminals to gather corporate data. These attacks usually follow a standard scenario.

Corporate e-mail addresses of employees receive messages that imitate typical notifications coming from business platforms such as SharePoint. These messages urgently ask the employees to follow a link to either read an important document or perform some other important action. If employees actually follow the recommendations of this e-mail, they will end up on a spoofed website containing a fraudulent form for entering their corporate account credentials. If an employee attempts to log in to this fake resource, this login information will end up in the hands of the phishing scammers. If a business platform is accessible not only from within the corporate network but also from outside of it, the cybercriminals could then log in to the resource using the employee’s account and collect the information they need.

Example phishing e-mail. An employee is asked to follow a link to read a fax message

The first wave of an attack launched against an organization may also be a phishing ploy aimed at hijacking the personal accounts of employees. Many users are “friends” with their colleagues on social networks and correspond with them in popular messengers, which may include discussions about work-related issues. By gaining access to an employee’s account, cybercriminals can skillfully coax the employee’s contacts into disclosing corporate information.

Luckily, simple mass e-mail phishing is promptly detected by most security products, and more and more users are becoming aware of these types of attacks. However, cybercriminals are resorting to more advanced types of attacks, such as phishing for data over the phone.

Phone phishing

The main difference between phone phishing and typical phishing attacks is that cybercriminals persuade their victim to give them confidential information over the phone instead of via a phishing web page. They also may use various methods to establish contact with their victim. For example, they can directly call specific employees or call around the entire company — if the database of employee contacts ended up in their hands, or they can distribute e-mail messages requesting that the employees call a specific number. The latter example is more interesting, so we will discuss this method in detail.

Let’s examine a potential scenario for such an attack. A company employee receives a phishing e-mail that is specially stylized as an official message from a large service provider such as Microsoft. The message contains information that requires the victim to make a quick decision. Cybercriminals may also try to intimidate the recipient. The example below states that child pornography was accessed from the victim’s computer. To resolve the issue, the cybercriminals request that the employee contact technical support at a specific number. If the victim actually calls the specific number, the cybercriminals could pose as Microsoft technical support personnel and dupe the victim into revealing their username and password for accessing the company’s internal systems.

Example e-mail message initiating a phone phishing attack

Cybercriminals often pose as technical support personnel or as representatives of the company’s IT department to gain the trust of its employees. This was exactly the technique used for the Twitter hack in the summer of 2020.

By obtaining employee credentials, they were able to target specific employees who had access to our account support tools. They then targeted 130 Twitter accounts – Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7.

— Twitter Support (@TwitterSupport) July 31, 2020

Message from Twitter Support regarding the incident

Twitter employees with access to internal systems of the company received phone calls supposedly from the IT department. During these conversations, cybercriminals employed social engineering techniques to gain access not only to the internal network of the company, but also to tools that enabled them to manage Twitter user accounts. As a result, the pages of many famous people showed fraudulent messages promising their readers that they would receive double any amount that they transferred to a specific bitcoin wallet. More details about this incident can be found in the Twitter company blog.

Examples of scam messages on Twitter

The victims of this incident included the company itself, which incurred reputational losses, and many Twitter users who were duped by the messages from the spoofed posts and actually transferred more than $110,000 in bitcoin. This perfectly illustrates the fact that the initially attacked company is not always the ultimate victim of corporate doxing, but it could be just an unknowing intermediary within a much larger cybercriminal campaign aimed at the company’s customers or partners. Ultimately, the reputation of all involved parties will be damaged.

Doxing of individual employees

Traditional doxing involving the collection of data on specific people could also be used in a larger attack against an organization. As we mentioned earlier, cybercriminals can employ BEC attacks based on specific information acquired from publicly accessible posts on social networks. However, this is not the only potential consequence of doxing, especially for cases of targeted data collection in which the attackers do not limit themselves to publicly available data sources but actually hack the accounts of a victim for the purpose of obtaining access to private content.

Identity theft

One result of doxing aimed at an individual employee may also be theft of their identity. Under a stolen identity, cybercriminals may circulate false information that results in a damaged reputation and sometimes financial losses of a company, especially if this information is attributed to a high-ranking employee whose statements are capable of provoking a serious scandal.

Let’s examine one of the potential attack scenarios involving identity theft. In this scenario, cybercriminals create a fake account for a high-ranking manager of their target company on a social network where the manager has not yet registered, such as Clubhouse. This account participates in discussions with a large number of users, and constantly makes provocative statements that are eventually reported in the media. As a result, company shares may lose value, and potential customers start trending toward the company’s competitors. Interestingly, cases of identity theft have already been observed in Clubhouse (albeit relatively minor cases so far).

Cybercriminals may also pose as a company employee for fraudulent purposes. For example, if a cybercriminal has obtained audio and video content involving the victim, such as from presentations at conferences, broadcasts, or their Instagram stories, the cybercriminal may employ “deepfake” technology. There have already been cases when scammers very convincingly imitated the voice of the CEO of an international company and persuaded the management team of one of their branches to transfer a large sum of money to the scammers.

Conclusion

Corporate doxing poses a serious threat to the confidential data of a company. This article provided examples showing how information that is publicly accessible and generally non-threatening to a company could actually lead to an attack that results in significant financial and reputational losses if such information falls into the hands of professional cybercriminals. The more sensitive the data accessed by cybercriminals, the more damage they are capable of inflicting. They could demand ransom for the confidential information, sell it on the dark web, or use it for subsequent attacks on customers, partners, and company departments responsible for financial transactions.

How to protect yourself

To prevent or minimize the risk of a successful attack on your company, you must first understand that skimping on your security tools is never a good idea. This is especially true in today’s environment, which is continually dealing with new technologies that could be exploited by cybercriminals. To lower the likelihood of confidential data theft:

  • Establish a rigid rule to never discuss work-related issues in external messengers outside of the official corporate messengers, and train your employees to strictly adhere to this rule.
  • Help your employees become more knowledgeable and aware of cybersecurity issues. This is the only way to effectively counteract the social engineering techniques that are aggressively used by cybercriminals. To do so, you could use an online training platform such as Kaspersky Automated Security Awareness Platform.
  • An employee who is well versed in cybersecurity issues will be able to thwart an attack. For instance, if they receive an e-mail from a colleague requesting information, they will know to first call the colleague to confirm that they actually sent the message.
  • Utilize anti-spam and anti-phishing technologies. Kaspersky provides several of these types of solutions, which are included in the following business-oriented products: Kaspersky Security for Microsoft Exchange Servers, Kaspersky Security for Linux Mail Server, Kaspersky Secure Mail Gateway, and the standalone product Kaspersky Security for Microsoft Office 365.

Threat landscape for industrial automation systems. Statistics for H2 2020

25 Březen, 2021 - 12:00

Figures

Indicator

H1 2020

H2 2020

2020

Global percentage of attacked ICS computers 32.6% 33.42% 38.55%

Percentage of attacked ICS computers by region

Northern Europe 10.1% 11.5% 12.3% Western Europe 15.1% 14.8% 17.6% Australia 16.3% 17.0% 18.9% United States and Canada 17.2% 16.5% 19.6% Eastern Europe 26.4% 28.0% 30.5% Southern Europe 27.6% 29.6% 33.1% Latin America 33.6% 34.3% 38.8% Russia 32.2% 34.6% 39.5% Middle East 34.0% 34.6% 40.2% South Asia 38.8% 41.3% 47.0% East Asia 42.9% 41.8% 46.3% Central Asia 43.7% 43.9% 48.8% Africa 45.6% 46.4% 51.2% Southeast Asia 49.8% 47.5% 53.9%

Main threat sources globally

Internet 16.7% 16.7% 20.5% Removable media 5.8% 5.4% 7.0% Email clients 3.4% 4.1% 4.4% Traits
  1. There is no longer a downward trend in the percentage of ICS computers on which malicious objects were blocked.
    Starting with the second half (H2) of 2019, we observed a decline in the percentages of ICS computers on which malicious objects were blocked. This was observed in industrial control systems (ICS) as well as in corporate and personal computing environments. This downward trend was not observed in the second half of 2020.

    • Globally, the percentage of attacked ICS computers in the second half of the year was 33.4%, which was 0.85 percentage points (p.p.) higher than the first half (H1) of the year.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Percentage of ICS computers on which malicious objects were blocked, by half-year, 2017 – 2020 (download)

    • The percentage of attacked ICS computers increased in 62% of countries.
      In H2 2020, the percentage of ICS computers on which malicious objects were blocked increased in relation to H1 in 62% of countries. In comparison, this trend was observed in 7% of countries in 2019, and the same was seen in H1 2020 compared to H2 2019.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Change in the percentage of attacked computers in countries of the world (p.p.) in H2 compared to H1, 2019 vs 2020 (download 1, 2)

      The maximum growth of this indicator in a country was 8.2 p.p. (in Saudi Arabia), while most countries observed no more than a 4 p.p. increase. Therefore, the global average change over the half-year was insignificant.

  2. The seasonal fluctuations typical of past years were not observed this year
    In previous years, the percentage of ICS computers on which malicious objects were blocked was at its maximum in March/April and October, while this indicator sagged between those months.In 2020, this indicator behaved differently. It reached its maximum in February and dropped almost to its minimum in May. In the first two months of summer, it grew to its near-maximum in July. In October, the percentage of attacked ICS computers was one of the lowest.

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Percentage of ICS computers on which malicious objects were blocked, by month, 2018 – 2020 (download)

  3. The percentage of ICS computers on which malicious email attachments were blocked increased
    • Globally, in H2 2020, the percentage of ICS computers on which malicious email attachments were blocked increased by 0.7 p.p. compared to H1.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Percentage of ICS computers on which malicious email attachments were blocked (download)

    • This indicator increased in all regions except East Asia, the US and Canada, Western Europe, and Russia.
    • In 73.4% of all countries in H2 2020, the percentage of ICS computers on which malicious email attachments were blocked increased compared to H1 2020.This is three times larger than the equivalent indicator for 2019 (23.6%).

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Change in the percentage of ICS computers (p.p.) on which malicious email attachments were blocked in H2 compared to H1, countries and territories, 2019 vs 2020 (download 1, 2)

  4. There was a rise in the percentage of ICS computers on which threats distributed over the internet and email, and spyware and miners were blocked
    • Malicious objects from the internet – web resources involved in the distribution or management of malware (+2.5 p.p.), and malicious scripts and redirects on web resources (JS and HTML) (+1.6 p.p.).
    • Typical threats distributed by email (+1.2 p.p.). – malicious MS Office and PDF documents (+1.2 p.p.).
    • Spyware (+1.4 p.p.) – Trojans, backdoors, and keyloggers.
    • Miners (+0.7 p.p.) – executable files for Windows.

    For all these threats, the indicators of H2 2020 exceeded the equivalent results of not only H1 2020 but also H2 2019.

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Percentage of ICS computers on which various types of malicious objects were blocked, H2 2019 – H2 2020 (download)

  5. In developed countries, the percentage of ICS computers attacked by ransomware increased
    Globally, the percentage of ICS computers on which ransomware was blocked decreased from 0.63% in H1 to 0.49% in H2.At the same time, this indicator increased in regions with developed countries:

    • +0.25 p.p. in the US and Canada
    • +0.23 p.p. in Australia
    • +0.13 p.p. in Western Europe

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Change in the percentage of ICS computers (p.p.) on which ransomware was blocked in H2 2020 compared to H1 (download)

Impact of the COVID-19 pandemic

In our H1 2020 report, we wrote about the impact of the COVID-19 pandemic on the changes that we observed in the attack surface and threat landscape for industrial enterprises and industrial automation systems. In H2 2020, we continued our observations and identified a number of trends that could, in our opinion, be due to circumstances connected with the pandemic in one way or another, as well as the reaction of governments, organizations and people to these circumstances.

Changes in seasonal fluctuations in the percentage of attacked computers

It can be seen in the ‘Percentage of ICS computers on which malicious objects were blocked’ diagram that in the past years the percentage of attacked ICS computers significantly decreased in summer months and in December. It is likely that this decrease was associated with traditional vacation periods: an infected USB drive cannot transfer malware from one computer to another all by itself, nor can an engineering workstation click on a link leading to a phishing website when the engineer is not there.

However, there was a noticeable change in the situation in 2020: we saw no significant seasonal fluctuations in the percentage of attacked computers. It is likely that this was due to changes in employee vacation schedules, since many people decided to go without vacations in the time of lockdown, travel restrictions, and closed borders.

Attacks on RDP remote connection services

Another effect of the pandemic was a noticeable increase in the percentage of ICS computers that could be accessed remotely via the RDP protocol.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers accessible via RDP, by months of 2020 (download)

It can be seen in the diagram above that the percentage grew continuously from January to April – the time when many organizations were dealing with the challenges of organizing work under an impending and actual lockdown. Then, after some fluctuations, the percentage decreased somewhat and stabilized at a slightly higher level than before the pandemic.

We do not have sufficient data to make conclusions as to what proportion of these computers could only be accessed from the industrial network of the enterprise, what part could be accessed from the corporate segment of the network and what percentage was available even outside the organization’s perimeter. However, we can state with confidence that the increase in the availability of ICS computers certainly affected the attack surface. Threat actors clearly took advantage of that – this is obvious from the following diagram, which shows the percentages of ICS computers on which brute force attacks on credentials used to access the RDP service were detected and blocked:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which attempts to brute force RDP passwords were detected, by months of 2020 (download)

It is easy to notice a certain synchronism in the changes occurring in these two parameters: the percentage of attacked RDP connections follows the percentage of UCS computers available via RDP almost all through the year (from January to October) with a delay of approximately one month, catching up (i.e., the changes are synchronized) in October and November.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which brute force attacks on RDP passwords were detected and percentage of ICS computers available via RDP (download)

We can only guess whether the one-month ‘delay’ in changes occurring in the percentage of attacked computers had to do with the speed with which attacks propagated on the enterprise network or the speed with which threat actors responded to changes in the opportunity landscape (attack surface).

Changes in ransomware priorities

One more potential consequence of the pandemic can be identified by analyzing the dynamics of ransomware attacks on industrial enterprises in different regions, which can be indirectly assessed based on the percentage of ICS computers attacked by ransomware. It can be seen in the ‘Change in the percentage of ICS computers (p.p.) on which ransomware was blocked’ diagram, as well as the diagram below that this percentage decreased in H2 2020 in all regions of the world except North America, Western Europe and Australia, where it did not just fail to decrease but increased several times over!

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which ransomware was blocked, H2 2019 – H2 2020 (download)

We believe that these curious dynamics could indicate the response of threat actors to the economic consequences of the pandemic. In those countries where the ‘creditworthiness’ of organizations decreased as a result of the pandemic, the number of attacks on industrial enterprises also fell (and so did the percentage of attacked ICS computers). At the same time, in countries where industrial organizations were generally more financially stable and were still able to pay ransom, the activity of attackers increased (and the percentage of attacked ICS computers surged). It can be hypothesized that the changes that we observed were due, among other things, to a shift in some groups’ focus when choosing victims towards organizations in more economically stable countries.

The full report is available on Kaspersky ICS CERT.