Malware Analysis Strange sample's network static analisys

[tim one]

I was looking for a sample to be analyzed when I noticed this:

https://www.reverse.it/sample/7a36c...2965b69a07103a222c12d59f93425?environmentId=1

It seems to contact hxxp://w*w.maliciouswebsite.com which seems to be not active, but the strange thing it has a banal and generic name.
It doesn't seem like a real malicious site, but a non-existing site.

But even more strange is that I have inserted SHA256: 7a36c3b22eb858d83b199c0ec60e4d816022965b69a07103a222c12d59f93425 in the search box on Malwr, which I often use and I got:

Malwr - Malware Analysis by Cuckoo Sandbox

It seems to be the same sample

But on Malwr it doesn't generate network connection.

I'm a little confused, I've decided not to analyze the malware focusing myself on this strange thing: why Reverse.it online analysis confirms network connections while Malwr analysis doesn't show network connections?

The only logical explanation that I can think is: in the code of the malware probably there is a hosts comparison with Malwr indicated in the variables and if the comparison is positive, the malware cannot be fully executed inside a known online sandbox (Malwr) and it doesn't perform any network action, in fact, the report does not contain any information concerning the network activity
The same sample subjected to a not known sandbox (Reverse.it) has released a positive report about network activities.

My doubt is what is this sample, probably the malcoder was doing some test, just a hypothesis.

 

[Wave]

Download the sample and analyse it in a Virtual Machine manually with tools like IDA Pro, Dependency Walker, PEiD, RegShot (if necessary), API Monitor, etc. Sometimes online analysis won't be reliable.

Since I had a spare few minutes I quickly read some static analysis of the PE (*.exe) and I can tell you that it does import network functions however when I checked the strings I found no evidence of a domain name - this does not mean that it doesn't connect to any websites (and it does import networking functions like HttpSendRequestW), therefore you should perform dynamic analysis to monitor where it attempts to connect too (if you can), or just disassemble the PE altogether to understand how it works based on the pseudo-code. (so find the start-up function, e.g. main function after Crt initialisation) and then start disassembling how it works to pseudo-code of C/C++, then read the pseudo-code to note on what it does at specific times, etc.

You don't need to go through the entire sample for every detail, most analysts will stop when they find malicious code evidence and then they'll mark it with the detection name corresponding to the evidence they had and move on to the next samples (since in real vendor companies they have so many samples to get through that they don't have the time to go through everything always).

Since I only had a spare few minutes for some quick-time analysis I believe malwr.com and it's analysis as opposed to reverse.it (and "maliciouswebsite.com" isn't active therefore if anything you would be right about your theory of it being a test by the malware author), but do dynamic analysis on the network activity if you can to check if it does try to connect to that host.

So analyse it manually and determine if it's malware/mark the detection name if you find malicious evidence. If not, mark as clean. (as I said I had a few minutes, I haven't checked if it's malware or not myself yet).

Good luck.

 

[tim one]

Download the sample and analyse it in a Virtual Machine manually with tools like IDA Pro, Dependency Walker, PEiD, RegShot (if necessary), API Monitor, etc. Sometimes online analysis won't be reliable.

Since I had a spare few minutes I quickly read some static analysis of the PE (*.exe) and I can tell you that it does import network functions however when I checked the strings I found no evidence of a domain name - this does not mean that it doesn't connect to any websites (and it does import networking functions like HttpSendRequestW), therefore you should perform dynamic analysis to monitor where it attempts to connect too (if you can), or just disassemble the PE altogether to understand how it works based on the pseudo-code. (so find the start-up function, e.g. main function after Crt initialisation) and then start disassembling how it works to pseudo-code of C/C++, then read the pseudo-code to note on what it does at specific times, etc.

You don't need to go through the entire sample for every detail, most analysts will stop when they find malicious code evidence and then they'll mark it with the detection name corresponding to the evidence they had and move on to the next samples (since in real vendor companies they have so many samples to get through that they don't have the time to go through everything always).

Since I only had a spare few minutes for some quick-time analysis I believe malwr.com and it's analysis as opposed to reverse.it (and "maliciouswebsite.com" isn't active therefore if anything you would be right about your theory of it being a test by the malware author), but do dynamic analysis on the network activity if you can to check if it does try to connect to that host.

So analyse it manually and determine if it's malware/mark the detection name if you find malicious evidence. If not, mark as clean. (as I said I had a few minutes, I haven't checked if it's malware or not myself yet).

Good luck.

Thanks for advices and explanations, I will do that!

 

[DardiM]

Thanks for the share

- Reversit put a warning message:"this analysis ran with the legacy Usermode Monitor. It is highly recommended to use the Kernelmode Monitor".

- I wonder if it was not a sample tested by the maker
(just to test the detection part : no need to put a working URL )

Edited :
=> to avoid confusion

 

[Wave]

"this analysis ran with the legacy Usermode Monitor. It is highly recommended to use the Kernelmode Monitor".
I wonder if it was not a sample tested by the maker

Unless the sample is capable of bypassing user-mode hooks or loads a device driver, it won't matter if it was monitored via user-mode or kernel-mode. User-mode monitoring would be hooking a bunch of APIs to log the actions it attempts to commit... Same for kernel-mode really, except kernel-mode monitoring this way would only work from an x86 system unless they had an x64 system set-up on their server which was already exploited to perform SSDT hooking on x64 systems (via a PatchGuard exploit, since KeDescriptorTable would need to be exported to access the System Service Dispatch Table and actually perform the pointer redirections).

Or if I am wrong maybe the service can sign up to this forum, quote me and explain how it works different, as I'd be very interested.

 

[DardiM]

Unless the sample is capable of bypassing user-mode hooks or loads a device driver, it won't matter if it was monitored via user-mode or kernel-mode. User-mode monitoring would be hooking a bunch of APIs to log the actions it attempts to commit... Same for kernel-mode really, except kernel-mode monitoring this way would only work from an x86 system unless they had an x64 system set-up on their server which was already exploited to perform SSDT hooking on x64 systems (via a PatchGuard exploit, since KeDescriptorTable would need to be exported to access the System Service Dispatch Table and actually perform the pointer redirections).

Or if I am wrong maybe the service can sign up to this forum, quote me and explain how it works different, as I'd be very interested.

In blue, I have just posted the warning on the www .reverse.it website.

Then :

@DardiM said : I wonder if it was not a sample tested by the maker

=> not linked with my sentence in blue, just "I wonder", from the whole thread
=> some AVs marked it as malware, so It was tested with real AVs.​

(When I make a conclusion from a precedent sentence, I always use "=>" )

About their warning message :
I don't use reverse.it but hybrid, will see how they explain this warning

Edited :
it won't matter if it was monitored via user-mode or kernel-mode

=> This is their explanation :

Automated Malware Analysis - VxStream Sandbox - Payload-Security.com - Kernelmode Monitor​

 

[tim one]

Staying on what we have in our hands, the analysis of the sample using the online sandbox sometimes produces reports that are not sufficient to provide a clear answer.
If the report shows the network activity for a certain domain, it is not certain that the domain in question is the only one that the malware is capable of contact. The same if the report does not provide any evidence relating to the activities of the network.
In the first case, the malware could contain a list of domains to use in case one of the resources contact is no longer reachable. In the second case, having identified the environment in which it was executed, the malware may have changed its behaviour and, therefore, the report produced by the sandbox will contain information partially or totally incorrect.

 

[DardiM]

So it may be a VM aware malware .
It has been marked by several AV tools
Antivirus scan for 7a36c3b22eb858d83b199c0ec60e4d816022965b69a07103a222c12d59f93425 at 2016-11-05 15:43:10 UTC - VirusTotal

one from 24/10/2016 (dd/mm/yy)

 

[tim one]

So it may be a VM aware malware .
It has been marked by several AV tools
Antivirus scan for 7a36c3b22eb858d83b199c0ec60e4d816022965b69a07103a222c12d59f93425 at 2016-11-05 15:43:10 UTC - VirusTotal

Yes I already posted VT report in my thread

 

[DardiM]

Yes I already posted VT report in my thread

I used your link

VT:

1x 2016-10-24 and others : 4x 2016-11-05​

malwr.com :

test : 2016-03-24​

=> strange

 

[tim one]

I used your link

VT:

1x 2016-10-24 and others : 4x 2016-11-05​

malwr.com :

test : 2016-03-24​

=> strange

I have re analyzed the sample on VT about an hour ago, because the previous VT report was quite old.
What do you think about the VT report? It seems not an actual malware, but as an ambiguous code ..strange!

 

[Wave]

I have re analyzed the sample on VT about an hour ago, because the previous VT report was quite old.
What do you think about the VT report? It seems not an actual malware, but as an ambiguous code ..strange!

Appears to have no genuine purpose and appears to be suspicious therefore you can flag it as malware anyway. Unless there is a reason not to flag it as malware, better safe than sorry.

it won't matter if it was monitored via user-mode or kernel-mode

=> This is their explanation :

Automated Malware Analysis - VxStream Sandbox - Payload-Security.com - Kernelmode Monitor

Yes, looks like the chances of it just evolving around kernel-mode hooking are quite high... And as for the user-mode monitor, they pretty much admitted it is based on API hooking (user-mode injection and then hook) with this part:

Nevertheless, the main downside of a user-mode monitor is the easy detection of its presence (the target process memory needs to be modified to intercept system library calls). Today, as malware is becoming more evasive and aware of sandbox systems, the playing field is not level anymore with an outdated technology such as that. Instead, any state-of-the-art sandbox system needs to implement monitoring that leaves the target process untampered, in order to solve both environment and monitor detection.

Therefore, they inject into the process which is created for the program being sand-boxed and they hook a dozen of APIs and when these APIs are called they will log this and log additional information based on the data from the parameters of the function being called and intercepted. This also allows them to redirect any API calls which can be used in a manner to destruct the system (/remove the logs) or evade the sandbox mechanisms.

This is exactly how most typical Host Intrusion Prevention Systems work (scrap that, it's exactly how they all work) these days due to 64-bit limitations (so they use this same interception method from user-mode so the product is compatible with both x86 and x64 versions of Windows from Vista and on-wards without limitation differences in protection). The only difference being is: a lot less functions are hooked compared to a sandbox and you can have alerts for specific behaviour being identified (since the BB/HIPS has to use the real-time logging to identify behaviour and block depending on the requested user action as opposed to just simply log the API calls and then interpret that data later on for a test score).

 

[DardiM]

Request URL:

• http ://www .maliciouswebsite.com/

Request Method:

• GET

Status Code:

• 200 OK

Remote Address:

• 50.63.202.59:80

=> very interesting to look at : 50.63.202.59 IP address information - VirusTotal​

=> 50.62.0.0 - 50.63.255.255 : Organization: GoDaddy.com, LLC (GODAD)
​

Response :

Html with iframe :

=> try to LOAD :

hxxps://mcc.godaddy.com/park/rz55qaO2LzuznaWiMaMapv5jLab=

blocked by uOrigin :

• EasyList : ||mcc.godaddy.com/park/$third-party,subdocument

=> If not blocked :
​

So, domain that was registered on mcc.godaddy.com to do its stuff