Malicious Photo Album App offers famous Japanese movie camera filter

A famous Japanese movie Your Name《你的名字》released this year, the graphic style brings the real scene of Japan into fantastic pictures.


A Chinese app developer EverPhoto 时光相册团队 has release such kind of camera filter “Shinkai Makoto filter 新海诚滤镜” to turn your photos into movie Your Name scenes. On the other hand, the app claim that offers free 3,000GB cloud storage.

The app was reported by many Taiwan and Hong Kong media that is malicious and stealing user information such as user contact, photo and other private information.

The app 時光相冊 require permissions such as accessing your contacts, location, SMS, photo, camera, WiFi connection information, etc.


The app review as below.


There are two AV vendor on VirusTotal consider this app as malware.



Another analysis from Payload Security stated that the app has 4 malicious indicators.







Antivirus is a software program whose main task is to protect, identify and remove any malicious software or virus. However, if we look closely at how the antivirus actually works in identifying and removing viruses, we would realize that it is not very difficult to bypass them.


There are many ways to bypass the antivirus most of them involve using automated tools. There is also a good framework known as known as “Veil Framework” that creates malicious binaries that are very good in bypassing antivirus.

Although automating things is good and saves time but it is also important to understand how the process of evading antivirus actually works. Also, modern day antivirus does flag the binaries created from automated tools. Hence, it becomes important to know manual techniques of evading antivirus.

In this article, I will modify the binary contents of a Netcat listener so as to bypass the most popular and commonly used anti-virus.

The Objective is to ensure that the Netcat listener should be undetected by the antivirus software and at the same time, it should be functioning without any issues.


To follow the steps in this article, it is important to have basic knowledge of assembly language and a general familiarity with a Debugger (we will be using Immunity in this case) and its usage.


Antivirus scanners mostly depend on a signature pattern from a local database to identify malicious files and viruses. Also, they scan the file while it is on disk and not in memory.

If we can alter the contents of our Netcat binary when it is on disk, the antivirus that scans the file will not be able to identify the signature since the binary contents of the file have been changed. Now when the file is opened, we revert the contents of the Netcat binary in memory to its original state to ensure that the file is successfully running.

Although modern-day antivirus does scan files in memory and try to replicate its behavior in a sandbox environment, there are other ways to bypass this restriction as well, but as of now we will focus on the scenario where the antivirus who do not scan file in memory.

1) We will first set-up the Netcat listener and scan it on virus
total website. This will give us an idea as to how many antivirus scanners detect the Netcat binary as a malicious file in its original state. The Netcat binary can be downloaded from this website:

Below are the results after scanning the Netcat binary on the virus
total website.

As you can see a good number of antivirus scanners identify this Netcat binary as malicious. Now we will attempt to decrease the detection ratio of this Netcat file (31/57) by altering the binary contents of the file.

2) What we will attempt to do is hijack the entry point of our malicious Netcat listener, redirect it to a STUB (which in this case will be a custom XOR encoder) which encodes the contents of the file. This stub will be small shellcode which can be placed in the dead-space available in Netcat binary.

After running the stub on the Netcat binary, you will notice that the contents of the Netcat file have completely changed. We can now scan this file on virus total website and see if the detection ratio of this Netcat file decreases.

In a real world scenario, we will save this encoded file on the victim’s computer but since its contents have changed it bypasses the antivirus, now when we run the file, XOR encoder will run on the file again while it is in memory and change the file back to its original content and the file will be launched successfully. This is because when XOR function is run on a code that is already being XOR’ed, it will return the original code.

3) Let us start by loading the Netcat file in the Immunity Debugger and look for some dead space code where we can place our stub.

As we can see, there is some dead-space in the Netcat binary which can be used to place our stub. In my case, the dead space starts at the address: 0040A972.

4) We will hijack the entry point the Netcat binary and redirect it to the dead space address (i.e., 0040A972). Also while hijacking the entry point, we will make a note of the initial instructions that are overwritten as these would have to be re-introduced again.

The Initial Instructions of the program are:

00404AC3    6A 18        PUSH 18

00404AC5     68 98C04000 PUSH nc.0040C098

00404ACA     E8 69030000 CALL nc.00404E38

We will hijack the entry point by overwriting the first instruction with a redirection to our dead-space code address. While overwriting the code we notice that the first two instructions are overwritten, these will have to be re-introduced in the code later.

5) Now we save the changes made to this binary by doing a right click and selecting Copy to Executable and save the file as nc1.exe.

Before we open this file and jump to our dead-space code address, it is important that we mark all the sections of this file as writable since our stub (custom XOR encoder) will have to encode the contents of the file. In the Netcat binary, we are encoding the text section of the file so we will mark the text section as writable.

To do this, open the nc1.exe file with a PE Editor like Lord PE. Select the text section of the file and do right click to edit the section header and select the writable option and save the changes.

6) Now let us open the nc1.exe file in the immunity debugger and take a jump (by pressing F7) to the dead-space code address.

From this address onwards we will encode the entire text section of the file using our custom XOR encoder. Before starting the encoding, we will make a note of the starting and ending address of the text section. This address is found in the debugger itself from the third instruction (after redirecting to the dead-space code) to the end of the file. Also,the starting and ending addresses of the text section can be known by clicking on the “M” tab (memory-map) in the immunity debugger.

In my case the starting and the ending address of the text sections of the file is:-

Start Address: 00404ACA

Ending Address: 0040A96D

7) Now we will write our custom XOR encoder stub. The custom stub will include the following instructions:-

0040A972    B8 CA4A4000     MOV EAX,nc2.00404ACA

0040A977    8030 0F    XOR BYTE PTR DS:[EAX],0F

0040A97A     40     INC EAX

0040A97B     3D 6DA94000 CMP EAX,nc2.0040A96D

0040A985    7E F0     JLE SHORT nc2.0040A977

0040A987     6A 18     PUSH 18

0040A989     68 98C04000 PUSH nc2.0040C098

0040A98E     E9 37A1FFFF JMP nc2.00404ACA

The first instruction moves the value of the starting address of text section (00404ACA) in the EAX register. Then we XOR the value of the EAX register with the 0F key. Now we increase the value of EAX. Then compare the value of EAX with the ending address of the text section (0040A96D). If the ending address is not reached then simply jump back to the second instruction (0040A977) and continue the process. After the ending, theaddress is reached simply reintroduce the initial instruction of the program and continue the normal execution.

8) After writing this stub, we will copy the changes to an executable and save the file as nc2.exe.

Now we will open this file and allow the stub to run and encode the entire text section of the file. After the text section is encoded, we will go to the starting address of text section, i.e., 00404ACA (by doing a right-click and selecting the option Go to>Expression in the immunity debugger) and select all the encoded data right to the end of the text section and copy the changes to the executable. Now we will save the file and rename it as nc3.exe.

We have now completely changed the contents of the text section of this file. If we scan this nc3.exe file on virus
total website, we can see that the detection ratio has been decreased significantly. (20/57)

In a real world scenario what will happen is the modified Netcat binary is saved on disk, since the binary is modified the signature is also changed and the antivirus is bypassed then when we open this file again, the custom XOR encoder will run on the file again and as we know if we run the XOR function again on a code that is already XOR’ed we will get the original contents back.

Hence, when the file is opened the XOR Encoder will revert the modified binary back to its original state in memory thereby bypassing the Antivirus.

9) Now the XOR encoder stub is the not the only way of writing custom encoders; there are many different ways of writing these encoders. For example, we can use a stub that adds 15 bytes to the code, then XOR’s it with a 0A key and then adds another 35 bytes to the code. If used on the nc.exe file the above code will look like this:-

MOV EAX,nc2.00404ACA





CMP EAX,nc2.0040A96D

JLE SHORT nc2.0040A977


PUSH nc2.0040C098

JMP nc2.00404ACA

Now we can encode the text section by running the above stub on the Netcat binary and then saving the changes to create the modified binary. Now we change our custom encoder to ensure that the binary can decode itself back in the memory. We simply alter the instructions in the following way so that the program can decode itself.

MOV EAX,nc2.00404ACA





CMP EAX,nc2.0040A96D

JLE SHORT nc2.0040A977


PUSH nc2.0040C098

JMP nc2.00404ACA

Similarly, we can write our own encoders to modify the binary contents of the file and bypass the antivirus.

10) Now apart from writing encoders, there is also another way to bypass antivirus and that is by renaming the sections of the binary. What we will do is open the Netcat binary in the immunity debugger and rename the .text section of the file to .bop.

We can do this by simply doing a right click on the text section, select edit header and rename it from .text to .bop. Then we save the changes to the file and exit the program.

11) After saving this file if we scan it on virus
total website, we see that the detection ratio of the antivirus has been further decreased (15/57) and this time, even popular antiviruses like Kaspersky and McAfee has been bypassed.


We can see that bypassing antivirus is not the most difficult job, we simply have to keep trying different techniques to be successful. There are multiple ways to bypass the antivirus and I have highlighted only a couple of easy ways. Hence, it is not ideal to depend only on antiviruses to protect critical assets.

Original Post:

Malware Hiding Techniques to Watch for: AlienVault Labs

What is Malware?

Malware can be a lot of things. It can be a virus, a worm, spyware, a Trojan horse, or ransomware. It’s basically any malicious program that you would not want on your computer.

Windows Registry

Lately it has become common to see malware hide in the Windows Registry. Why the Windows registry? The Windows registry is quite large and complex, which means there many places where malware can insert itself to achieve persistence. A good example of this behavior is Poweliks. Poweliks sets a null entry utilizing one of the built-in Windows APIs, ZwSetValueKey, which allows it to create a registry key with an encoded data blob. I’m not sure why the Windows API allows a null entry, but it does. This is one of the many ways that malware can utilize the Windows registry to hide out, autostart, and maintain persistence on many systems.

Here’s an OTX pulse on Poweliks:

Malware Hiding Techniques to Watch for AlienVault Labs OTX pulse on Poweliks

Process Injection

Process injection is exactly what it sounds like. It is injecting some bits of code into a running process. Malware leverages process injection techniques to hide code execution and avoid detection by utilizing known “good” processes such as svchost.exe or explorer.exe. To inject itself into known good processes, malware writers use built-in Windows APIs. One of them is setting debug. When a process sets as debug, it gains access to many of the debug API calls, such as attaching to other processes and instructing processes to allocate additional memory. Once a process has allocate more memory, then a malicious process can inject whatever code it wishes into that process.

A great example of malware that uses process injection is Poison Ivy. Poison Ivy’s process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there. Poison Ivy does what we call “sharding.” Instead of having one giant memory block, it has a whole bunch of tiny memory blocks split all over the process and sometimes in various processes. A great example of malware that uses process injection is Poison Ivy. Poison Ivy’s process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there.

Here’s an OTX pulse on Poison Ivy:

Malware Hiding Techniques to watch for AlienVault Labs Poison Ivy and Links to an Extended PlugX Campaign

  • 4SHA256
  • 5SHA1
  • 6MD5

Process Hollowing

Another technique related to process injection is process hollowing. ‘Hollowing’ is a process where you take a known good process and start it in a suspended state. When that code is loaded and about to execute, you scoop some of the good code out (like with an ice cream scoop). Now there is available space where a bad guy can place whatever code they like, maybe change a few headers on the top and bottom to make everything seem okay, and then restart the execution process. As far as a user knows, this process looks like a normal system process started by Windows. It is therefore much more difficult for reverse engineers and memory forensics people to analyze.

Dridex is a very good example of a malware family that often uses process hollowing. Here’s an OTX pulse on Dridex:

Malware Hiding Techniques to Watch for AlienVault Labs Dridex, Vawtrak and others increase focus on Canada Process Hollowing

  • 1URL
  • 13SHA256

Process List Unlinking

Process List Unlinking is another key concept. A process is anything that is running on your computer, whether it be in user space or kernel space. Process List Unlinking involves a double-linked list that contains all “active” processes. It’s important because unlinking will result in a process being hidden from all “active” tools. This can be done using ZwSystemDebugControl() or by mapping \Device\PhysicalMemory. Inside the process list is a list of every single process that is running and inside the process object is forward-pointed and backwards-pointed into the process in front of it or the process behind it to make a double-linked list.

Malware Hiding Techniques to Watch for AlienVault Labs Process List Unlinking

A Flink to the process before it and then Blink to the one in front of it effectively removes the process from the list. More advanced malware will take this a step further and after they remove that process from the list, they will also write over that bit of memory, so even with memory forensics you wouldn’t be able to locate that process.

There are tools that security researchers can use to find hidden malicious code, such as

  • PsAc4veProcessHead traversal
  • Pool tag scanning for processes
  • Pool tag scanning for threads
  • PspCidTable

This is an example bit of code that somebody would use to unlink from the process list.

Example of bit code malware hiding techniques to watch for AlienVault Labs

DLL List Unlinking

Malware can also hide by manipulating the DLL list. Just like the process list, a DLL list has a double-linked list that points to the DLL in front and behind, and again just like the process lists are APIs that can be called to rewrite entries in the DLL list, remove that DLL entry and wipe out that bit of memory to help hide the malware from memory forensics or from backup tools. This is used a lot in rootkit activity. Here’s a graphic explaining DLL lists:

malware hiding techniques to watch for AlienVault Labs DLL List Unlinking

Here we have another example of code used to unlink from the DLL list:

malware hiding techniques to watch for AlienVault Labs example of code used to unlink from the DLL list

You can see where it is writing over the one in front, the one behind, and then wiping out the memory and the zero memory function call. One other thing to remember about DLL and process list linking is that all that can be done from the user space, so I don’t need kernel-level administrative rights.

Kernel Module List Unlinking

Kernel modules are the next level down. A kernel module is any of the modules that is loaded into the kernel. Like the DLL and process list, the kernel modules have their own list that can be queried with APIs and return every kernel module that is loaded. There are also debug APIs that can remove one DLL module from the list and zero it out. This is especially important because at the kernel level when something is zeroed out it makes it lot harder to find. This access is like ring zero access – definitely associated with rootkit activity. Generally, a piece of malware will execute in user space and then try a kernel-level exploit to get kernel administrative access; it then drops the main rootkit, which would then zero itself out inside the kernel module list process list. At this point, the malware is very well hidden and it will be very difficult to find.

How Kernel Module List Unlinking Works:

Kernel Module List Unlinking Malware Hiding Techniques to Watch fro AlienVault Labs

Original Post:

Comparing Free Online Malware Analysis Sandboxes

Corporate computer networks face cybersecurity threats on a daily basis. Some of these threats consist of malware that is not yet recognized and, as a consequence, is not stopped by security solutions. This malware eventually ends up on a victim’s workstation or on a corporate server,

Corporate computer networks face cybersecurity threats on a daily basis. Some of these threats consist of malware that is not yet recognized and, as a consequence, is not stopped by security solutions. This malware eventually ends up on a victim’s workstation or on a corporate server, where it can cause havoc. Malware analysis sandboxes can be used to extract useful information from this type of malware to improve your protection level.

When a security incident is caused by malware, it is important to contain the incident, assess the damage it has caused and extract information on its behavior. Collecting this information allows you to find other similar infections on your network and develop updated protection rules for your existing security infrastructure.

Indicator of Compromise

This collected information can serve as an indicator of compromise (IOC). These are artifacts on a computer that indicate a high likelihood of an infection. It is intelligence that you can use and share — for example, via STIX or CybOX — to update your security devices.

What type of information will you be looking for? Ask yourself the following questions:

  • What are the file hashes (MD5, SHA1, etc.)?
  • How exactly does it affect the system?
  • What files does it create or change?
  • Are there recognizable pointers (mutexes)?
  • How does it spread or propagate?
  • Does it use specific IP addresses, network ports or domains?

How Do You Get the Information?

How do you find the answers to these questions? If you have an infected machine, you can analyze it. Often, there’s not enough time to conduct a thorough investigation. It might even be difficult to pinpoint the exact malware that caused the issue.

If you have a sample of the malware, you can apply static analysis and extract the parts of the information that are useful to you. But this will not give you the same information as observing how the malware behaves in a controlled environment such as a sandbox.

There are three basic types of sandboxes:

  • A custom-built lab with your own toolset;
  • A purchased solution (preferably on-premises);
  • A publicly available sandbox.

Having a custom-built lab or a purchased solution is not always available for everyone, either because it is too complex, too time consuming or too expensive. That is when the free malware analysis sandboxes can help. Their reports on analyzing malware are meant to give you a basic initial view on what the malware does and provide easy extraction of some basic IOCs.

What Do You Share?

Public sandboxes are, obviously, publicly available. You should understand that everything you share or upload to these sandboxes is accessible to everyone — including the bad guys.

There are a number of circumstances where you do not want to upload your samples to a public service. If you upload a malware sample that was specifically targeted for your environment, then you’re essentially giving away to your adversaries that you have detected their operations. Similarly, it’s not a good idea to upload samples that contain specific information about your environment, such as hard-coded passwords or configuration settings. You should also refrain from sharing samples that contain confidential user or customer data or material that is copyright-protected. Don’t forget, you’re sharing these files with the whole world.

If you run into a situation where you cannot use a public sandbox, then you should run an on-premises sandbox. Note that some antivirus solutions might automatically submit your samples to their networks without clearly notifying you. This is important to consider when you do the pre-analysis.


VirusTotal VirusTotalis a subsidiary of Google that analyzes files and URLs. Apart from the free interface, VirusTotal also has both a private and a public API.

The results from VirusTotal include the detection results of the malware by the supported antivirus engines. Although these engines are not exactly the same as the ones used by end users, they give information that tells you if the uploaded malware is already detected. This allows you to better evaluate if you are at risk.

You can upload different types of files, such as a Windows executable, Android APKs, PDFs, images and JavaScript code.

The online reports are not individually downloadable, but they are very detailed. They give you everything you need to know on what files the malware accessed, what it changed in the registry and how it behaved. It is not possible to download the analyzed samples or get a network capture of what happened. The online report does give you an overview of the detailed network requests.



Anubis is developed by the International Secure Systems Lab and analyzes both files and URLs. It supports Windows executable files and Android APKs.

Although the interface isn’t as slick as some of its counterparts, it gives you access to everything that you need to know. The reports can be downloaded as HTML, XML, PDF or text. You can download the network captures in pcap format, but you cannot download the samples. Anubis reports also tell you if the malware communicated with specific device paths.


The VxStream sandbox is powered by Payload Security. It only analyzes files and does not do URLs. It supports Windows executable files, Office files, PDF files and executable JAR files.


You can download the reports, the network captures and the samples. The reports indicate YARA signature matching and give you information on possible anti-VM emulation checks — a technique often used by malware to prevent analysts to run the sample in a virtualized environment. The reports and analysis interface are very appealing, with an intuitive access to the necessary details.



The sandbox from Malwr is a free malware analysis service and is community-operated by volunteer security professionals. It only analyzes files and does not do URLs.

It is built on top of the Cuckoo sandbox and supports Windows executables.

You can download the samples if they are shared by the uploader. A downloadable network capture is not available, but you do get, for example, the full HTTP request in the online report. If you cannot set up your own Cuckoo sandbox, this is an excellent replacement solution.

A useful addition to Malwr is a visualization provided by MalwareViz. You first have to analyze the file with Malwr and then use the returned reference URL to feed the visualizer.

Compare Them

Below is a table comparing the features of the different online sandboxes. They all run different Windows flavors. The configurations are basic, but of course, these will always be different from your real production environment. This is something you’ll have to live with when using a free public sandbox.

All of the malware sandboxes provide the upload service via a secured SSL connection and give screenshots of what visually happened.

VirusTotal Anubis VxStream Malwr
Windows executable X X X X
Office files X X X
PDF files X X X
Java files X X X
Android APK X X
File details X X X X
Display hashes X X X X
DLL usage X X X X
Mutexes/Mutants X X X X
Registry changes X X X X
File interaction X X X X
Started processes or services X X X X
Network activity X X X X
Device monitoring X
YARA support X
Download sample X X
Download PCAP X X


Free online sandboxes are a great replacement if you do not have your own in-house solution. They provide good information for a basic analysis and getting some early indicators ready to scan your infrastructure for existing infections. It also provides a quick way to further protect your infrastructure.

There are some limitations, however. Integrating the information from the online reports with your own environment still requires some manual work; having access to an API will greatly improve this process. They are also not fitted for analyzing targeted malware and evaluating how malware behaves in a specific environment.

Beyond these limitations, these online tools give you good initial insight on malware behavior and are an excellent addition to your toolset for protecting your infrastructure.

Original Post:

Trick or Treat! Google issues warning of critical Windows vulnerability in wild

Privilege escalation bug in Windows kernel is “being actively exploited.”

Enlarge / Win32k.sys has some problems. Again.

Recently, Google’s Threat Analysis Group discovered a set of zero-day vulnerabilities in Adobe Flash and the Microsoft Windows kernel that were already being actively used by malware attacks against the Chrome browser. Google alerted both Adobe and Microsoft of the discovery on October 21, and Adobe issued a critical fix to patch its vulnerability last Friday. But Microsoft has yet to patch a critical bug in the Windows kernel that allows these attacks to work—which prompted Google to publicly announce the vulnerabilities today.

“After 7 days, per our published policy for actively exploited critical vulnerabilities, we are today disclosing the existence of a remaining critical vulnerability in Windows for which no advisory or fix has yet been released,” wrote Neel Mehta and Billy Leonard of Google’s Threat Analysis Group.”This vulnerability is particularly serious because we know it is being actively exploited.”

The bug being exploited could allow an attacker to escape from Windows’ security sandbox. The sandbox, which normally allows only user-level applications to execute, lets programs execute without needing administrator access while isolating what it can access on the local system through a set of policies.

But by using a specific type of call to a legacy support Windows system library generally used for the graphics subsystem—win32k.sys—malicious code can escalate its privileges and execute outside of the sandbox, allowing it to execute code with full access to the Windows environment. Win32k.sys has been a problem before: Microsoft issued a warning back in June about a similar privilege escalation problem that had not yet been exploited, and another arrived in August.

Google Chrome already blocks this sort of an attack on Windows 10 using a modification to the Chromium sandbox called “Win32k lockdown.” That approach explicitly denies access to the library. However, code executed in other Web browsers or otherwise launched outside Chrome could still exploit the vulnerability.

Original post:

Up ↑