Dataset from “xDedic” Marketplace Suggests Government, Corporate RDP Servers Targeted

https://www.flashpoint-intel.com/wp-content/uploads/2016/06/cropped-FP_Favicon-32×32.pngDataset from “xDedic” Marketplace Suggests Government, Corporate RDP Servers Targeted

Background The xDedic marketplace is a predominant cybercriminal marketplace on the dark web known for hosting sales of access to compromised Remote Desktop Protocol (RDP) servers. RDP is Microsoft’s proprietary protocol that provides users with a graphical interface to connect to another computer over a network connection. System administrators frequently use RDP to control servers […]

The post Dataset from “xDedic” Marketplace Suggests Government, Corporate RDP Servers Targeted appeared first on Flashpoint.

Background
The xDedic marketplace is a predominant cybercriminal marketplace on the dark web known for hosting sales of access to compromised Remote Desktop Protocol (RDP) servers. RDP is Microsoft’s proprietary protocol that provides users with a graphical interface to connect to another computer over a network connection. System administrators frequently use RDP to control servers and PCs remotely. RDP clients are available for all of the modern operating systems (OS), including Linux, Unix, OS X, iOS, and Android. Server software exists for Windows, Unix, and OS X.
In order to gain RDP access, threat actors typically launch bruteforce attacks by systematically checking all possible RDP username and password combinations until a match is found. This primitive form of attacking requires formidable computing power with distributed resources and is most successful against short, weak passwords.
While these attacks tend to be less effective when users’ RDP login credentials include passwords that are longer and more complex, the use of large botnets can enable some attackers to effectively gain RDP access under such circumstances. Indeed, xDedic cybercriminals typically begin launching large-scale scan and bruteforce attacks to collect as much information as possible before sorting its potential value.
As RDP servers are established in order to provide remote access to office resources, they can provide an initial vector into target organizations. Once a hacker secures login credentials for RDP access, he or she effectively owns the system where the RDP server is installed. In addition to being able to launch external attacks and move laterally within networks, attackers are then able to plant malicious software, exfiltrate data, and/or manipulate network settings.
Many actors also sell the login credentials of targeted systems as commodities on underground marketplaces such as xDedic. As the exploitation of RDPs becomes more popular, numerous threat actors continue to inquire about how to properly configure their compromised RDPs to ensure that their illicit activities remain undetected.
Image 1: xDedic dataset reveals Education, Healthcare, Legal, and Aviation among most-frequently-targeted sectors
Analysis of xDedic Dataset
Flashpoint analysts gained access via an external link to one previously-exposed xDedic dataset, which contained information belonging to over 85,000 servers. The prolific threat actor “thedarkoverlord,” notorious for targeting healthcare entities, is believed to have leveraged this dataset for at least some of their breaches. Indeed, access to open RDPs belonging to healthcare organizations could provide particularly valuable resources to threat actors. Based on Flashpoint’s analysis of the exposed xDedic marketplace data, the most exploited sector appears to be education, followed by healthcare, legal, aviation, and government. The United States, Germany, and Ukraine appear to be the most frequently-targeted countries.
Image 2: Dataset analysis suggests RDP compromises most common in U.S., Germany, and Ukraine
Assessment
Leveraging RDPs is a convenient way to enable access to systems over the Internet, especially in corporate environments that have remote IT support staff. Utilizing RDPs, however, is an organizational risk, given that remote attackers — including the prolific threat actor “xDedic” — may be able to guess or brute force the login credentials.
Moreover, exposing RDPs to the Internet often relies on the presumed lack of a remotely-exploitable vulnerability in the RDP’s implementation. While the abuse of corporate and government RDPs is likely to continue, understanding the criminal tactics, techniques, and procedures (TTPs) listed above can help mitigate attacks from this threat vector.
Image 4: The xDedic toolkit that includes xDedic RDP Client, xDedic RDP Patch, and xDedic Socks System is used to target corporate and government entities.The post Dataset from “xDedic” Marketplace Suggests Government, Corporate RDP Servers Targeted appeared first on Flashpoint.
Go to Source
Author: Chelsea Sawicki

Powered by WPeMatico

Threat Actors Leverage “Phonecord” Bot to Harass Victims

https://www.flashpoint-intel.com/wp-content/uploads/2016/06/cropped-FP_Favicon-32×32.pngThreat Actors Leverage “Phonecord” Bot to Harass Victims

Although the majority of cyber threat actors are fueled by the desire for financial or political gain, some actors lack traditional motivations altogether. Often referred to as “attention-seekers”, these actors’ malicious activities are driven typically by nothing more than a desire to attract attention by causing chaos for their own amusement. Despite their reputation for […]

The post Threat Actors Leverage “Phonecord” Bot to Harass Victims appeared first on Flashpoint.

Although the majority of cyber threat actors are fueled by the desire for financial or political gain, some actors lack traditional motivations altogether. Often referred to as “attention-seekers”, these actors’ malicious activities are driven typically by nothing more than a desire to attract attention by causing chaos for their own amusement. Despite their reputation for nonsensical campaigns, erratic targeting, and low technical sophistication, attention-seekers’ schemes can yield anything from mild nuisances to economic or even psychological distress. In fact, Flashpoint analysts recently observed groups of attention-seekers launch a series of vicious attacks that subject victims to an age-old and universally-despised form of abuse: telephone harassment.
Since this particular form of telephone harassment first emerged in late April 2017, groups of attention-seeking actors have harassed a wide range of individuals and organizations via a telephone bot known as “Phonecord”. Although telephone bots in and of themselves are nothing new, Phonecord is relatively unique because it utilizes the social and communication application Discord, which enables users to make international calls directly and easily from the app’s voice chat functionality. And because those seeking to use the Phonecord bot have the option to pay for the service in Bitcoin, most users remain relatively anonymous. While Discord has long been popular among the gaming community, the app’s ease of use and ability to withstand distributed denial-of-service (DDoS) attacks has given rise to its heavy usage among cyber threat actor communities.
Thus far, victims of Phonecord harassment schemes include:
   • United Kingdom National Crime Agency (NCA)
   • Federal Bureau of Investigation (FBI)
   • Various popular pizza chain restaurants
   • Hotels
   • Individuals whose personally identifiable information (PII) has been exposed previously
Many of these victims have been harassed in a manner that resembles a common tactic known as “Swatting”, which occurs when a threat actor makes numerous “prank calls” to emergency services in an attempt to dispatch a large number of law enforcement officers to a specific address. Indeed, Flashpoint analysts observed various threat actors utilize Phonecord in similar yet more lighthearted manner: rather than dispatch emergency services, they ordered a large number of pizzas from multiple restaurants to be delivered to the same address. Not only does this leave the unsuspecting victim with an unusually large amount of pizza, it burdens them with the high cost of paying for such pizzas upon delivery. While these types of schemes yield no financial reward for the threat actors involved, they do satisfy these actors’ cravings for attention and amusement at the cost of victims’ discomfort.
In fact, multiple threat actors have even been known to utilize the Phonecord bot to harass certain individuals and law enforcement agencies on repeat occasions. Unfortunately for many threat actors, their multiple attempts to call numbers including “911”, the suicide hotline, and other emergency services hotlines were unsuccessful because Phonecord’s configuration blocks calls to such numbers.
Image 1: Actors attempt to make calls to “911” and make implications about using the service for “swatting,” in which threat actors place calls to the police with the intent of directing police SWAT teams to victims’ addresses. Image 2: In an April 25, 2017 post, an actor attempts to make a call to the suicide hotline.
Assessment & Mitigation
One administrator of the Phonecord bot service most notably took credit for a DDoS attack that took down servers for the popular game Minecraft for an extended period in June 2014. Although this actor and the other administrators have not advertised Phonecord explicitly as a criminal service, numerous instances of abuse have evidently become present.
Flashpoint analysts assess with high confidence that threat actors will likely continue to use the Phonecord bot to carry out harassment campaigns against various individuals and organizations unless the administrators of the service institute additional controls and countermeasures.
The most effective way to avoid becoming the victim of Phonecord and other telephone bot harassment schemes is to exercise extreme caution in safeguarding personal information such as telephone numbers and home addresses. For those whose personal information has already been exposed, taking additional measures by changing telephone numbers and opting to use a P.O. box as opposed to a residential address on all correspondence will serve as additional barriers that may help deter the efforts of some actors.
Victims of telephone bot harassment and/or other malicious schemes are encouraged to report such incidents to the Internet Crime Complaint Center: https://www.ic3.gov/default.aspxThe post Threat Actors Leverage “Phonecord” Bot to Harass Victims appeared first on Flashpoint.
Go to Source
Author: Chelsea Sawicki

Powered by WPeMatico

Karmen Ransomware Variant Introduced by Russian Hacker

Karmen Ransomware Variant Introduced by Russian Hacker

On March 4, 2017, a member of a top-tier cyber criminal community mentioned a new ransomware variant called “Karmen.” We’ve taken a closer look.

The post Karmen Ransomware Variant Introduced by Russian Hacker appeared first on Recorded Future.

     

On March 4, 2017, a member of a top-tier cyber criminal community with the username “Dereck1” mentioned a new ransomware variant called “Karmen.”
Further investigation revealed that “DevBitox,” a Russian-speaking cyber criminal, was the seller behind the Karmen malware on underground forums in March 2017.
However, the first cases of infections with Karmen were reported as early as December 2016 by victims in Germany and the United States.

Mentions of “Karmen” by DevBitox or Dereck1 on dark web and special access sources in Recorded Future, which include posts by the actors selling the Karmen malware on the aforementioned criminal forum.

Mentions of Karmen malware on the web over time.
Background
The Karmen malware derived from “Hidden Tear,” an open source ransomware project, available for purchase by anyone. As is typical for ransomware infections, Karmen encrypts files on the infected machine using the strong AES-256 encryption protocol, making them inaccessible to the user and may trigger a ransom note or instructions demanding that the user pay a large sum of money to obtain the decryption key from the attacker.
A notable feature of Karmen is that it automatically deletes its own decryptor if a sandbox environment or analysis software is detected on the victim’s computer.

Here are screenshots of the affiliate’s page seen by purchasers of Karmen. Configuration of Karmen through this interface allows actors to change the malware’s settings using a control panel that requires very minimal technical knowledge.

The “Clients” page allows for tracking of computers infected with the virus, including the status of any ransom that’s been paid.

The dashboard gives an overview of other relevant information including the number of clients they have, how much money they’ve earned, and updates to the Karmen software.

On the computer of a user infected with Karmen the above message is displayed, warning them not to interfere with the malware.
Description of Karmen Malware Provided by DevBitox
Multi-threaded
Multi-language
Supports .NET 4.0 and newer versions
Encryption algorithm: AES-256
Adaptive admin panel
Encrypts all discs and files
Separate BTC wallet for each victim
Small size
Automatic deletion of loader
Automatic deletion of malware (after payment was received)
Minimal connection with control server
Robust control panel
Almost FUD (1/35)
Automatic file decryption after received payment
T2W compatible
File extensions remain the same
Detection of anti-debugger/analyzers/VM/sandbox
Automatic deletion of decryptor if sandbox environment is detected on victim’s computer*
Light version: obfuscation and autoloader only
Full version: detection of analyzing software
*Or if an analyzing software is detected
Notes
Application .NET dependent
Support infrastructure: PHP 5.6, MySQL, “file()” function must be activated on the server
Rebuild: free (up to three copies)
Updates: free
Price: $175
Known Indicators
File Name: joise.exe
File Name: n_karmen.exe
File Name: build.exe
File MD5: 9c8fc334a1dc660609f30c077431b547
File MD5: 56b66af869248749b2f445be8f9f4a9d
File MD5: 521983cb92cc0b424e58aff11ae9380b
SHA1: dc875c083c5f70e74dc47373a4ce0df6ccd8ae88
SHA1: f79f6d4dd6058f58b384390f0932f1e4f4d0fecf
SHA1: 2a3477ea2d09c855591b3d16cfff8733935db50b

Video presentation of Karmen ransomware operation. Please note although this video appears on the Recorded Future YouTube channel it was produced by DevBitox as a marketing tool for their ransomware.
The seller has admitted he was only involved with web development and control panel design; the malware is utilizing the open source encryption project “Hidden Tear” and was created by an unknown associate operating out of Germany.
As of this writing, 20 copies of Karmen malware were sold by DevBitox, while only five copies remain available to potential buyers.
The post Karmen Ransomware Variant Introduced by Russian Hacker appeared first on Recorded Future.
     
Go to Source
Author: Diana Granger

Powered by WPeMatico

It’s Cheap, It’s Easy, It’s Dangerous: Karmen Ransomware Hits the Criminal Black Market

It’s Cheap, It’s Easy, It’s Dangerous: Karmen Ransomware Hits the Criminal Black Market

This episode focuses on a new ransomware variant called “Karmen” that’s cheap and easy to use for cyber criminals. Andrei Barysevich provides more detail.

The post It’s Cheap, It’s Easy, It’s Dangerous: Karmen Ransomware Hits the Criminal Black Market appeared first on Recorded Future.

     

Over the last two years, ransomware has become the hottest commodity in the criminal black market. And we do mean commodity — it’s getting cheaper and more accessible to crooks, even the unskilled ones.
On March 4 of this year, a leading cyber criminal, who goes by the name “Dereck1,” mentioned that there was a new ransomware variant out called “Karmen.” But Dereck1 wasn’t the one hawking this in the criminal market. Instead, it’s a Russian speaker who goes by the name of “DevBitox.”
The first infections seem to go back to December of 2016, with victims in Germany and the United States reporting infection. DevBitox is no cryptographic ace — by his own admission, he was involved only with web development and control panel design, the criminal customer’s user experience. But Karmen is interesting not only because it’s dangerous, but because it’s cheap, and because it affords some insight into the way criminal markets function. Joining us to talk about Karmen is Andrei Barysevich, Director of Advanced Collection at Recorded Future.

This podcast was produced in partnership with the CyberWire and Pratt Street Media, LLC.
The post It’s Cheap, It’s Easy, It’s Dangerous: Karmen Ransomware Hits the Criminal Black Market appeared first on Recorded Future.
     
Go to Source
Author: Amanda McKeon

Powered by WPeMatico

Chinese and Russian Cyber Communities Dig Into Malware From April Shadow Brokers Release

Chinese and Russian Cyber Communities Dig Into Malware From April Shadow Brokers Release

As of April 15, the Chinese cyber community had begun to investigate the most recent release of malware from the Shadow Brokers group. Here’s a closer look.

The post Chinese and Russian Cyber Communities Dig Into Malware From April Shadow Brokers Release appeared first on Recorded Future.

     

As of April 15, the Chinese cyber community had begun to investigate the most recent release of malware from the Shadow Brokers group. Security researchers and cyber actors reversed several of the tools and were particularly interested in the exploit framework (named FUZZBUNCH), the SMB malware (ETERNALBLUE), and the privilege escalation tool (ETERNALROMANCE).
Chinese-speaking actors additionally focused on the unique malware trigger point and some claimed that the patches for CVE-2017-0143 through -0148 were insufficient because they did not address the base code weaknesses.

Mentions of one of the tools, ETERNALBLUE, on the Chinese language web over time.

Mentions of Shadow Brokers-released malware on the Chinese language web and from Recorded Future sources.
The surprising recent release has also stirred up great interest among Russian-speaking cyber criminals. Only three days after the data was leaked, a well-respected member of the top-tier dark-web community provided a detailed setup tutorial of weaponizing the ETERNALBLUE exploit as well as the DOUBLEPULSAR kernel payload.

Mentions of one of the tools, ETERNALBLUE and DOUBLEPULSAR, on the Russian language web over time.
In a separate thread, another member of the community, solicited help from other members in utilizing a proper exploit for a vulnerable Server Message Block version 1 (SMBv1), identified at the time of scanning a victim’s environment. Several members recommended using the recently released ETERNALBLUE exploit and admired its usefulness.
Background
Shadow Brokers is probably a hacker group that first came to public awareness in August 2016. While membership of the Shadow Brokers group remains unknown, it has both advertised for sale and publicly released hacker tools and exploits which the group claims were written and used by the U.S. National Security Agency (NSA).
Impact
Discussions in the Chinese and Russian cyber communities indicate that there is broad interest in these capabilities released by Shadow Brokers. Chinese users are particularly interested in the unique malware triggers and many feel the underlying vulnerability exploited by these toolsets has not been completely mitigated by the patches.
Further, Chinese APT groups have demonstrated an ability to quickly weaponize zero-day vulnerabilities, in as little as three days after public release in one instance.These three factors combine to increase the risk that malicious Chinese actors may reuse or repurpose this malware.
Recorded Future customers should set up alerts on these tools and the corresponding vulnerabilities, patch critical systems immediately, and remain vigilant to unique variations on these exploitation techniques.
The post Chinese and Russian Cyber Communities Dig Into Malware From April Shadow Brokers Release appeared first on Recorded Future.
     
Go to Source
Author: Insikt Group

Powered by WPeMatico

Going Dark: Fact vs. Fiction on the Dark Web

Going Dark: Fact vs. Fiction on the Dark Web

What is the dark web really like? In this episode, we take a tour of the dark halls and back alleys of the dark web to separate fact from fiction.

The post Going Dark: Fact vs. Fiction on the Dark Web appeared first on Recorded Future.

     

Mention the dark web and many people summon imagery of a massive, mysterious online criminal underground, where all manner of products and information are bought, sold, and traded, hidden away from the prying eyes of the public and law enforcement.
But, is that really what it’s like, or is that just cyber security marketing hype?
In this episode, we take a tour of the dark halls and back alleys of the dark web with the aim of separating fact from fiction. We’ll learn the truth about the people and products on the dark web, and find out the part it plays in threat intelligence today.
Our tour guides are Andrei Barysevich, Director of Advanced Collection at Recorded Future, and Emily Wilson, Director of Analysis at Terbium Labs.

This podcast was produced in partnership with the CyberWire and Pratt Street Media, LLC.
The post Going Dark: Fact vs. Fiction on the Dark Web appeared first on Recorded Future.
     
Go to Source
Author: Amanda McKeon

Powered by WPeMatico

Threat Intelligence: A Critical Defense Tool for Your Security Operations

Threat Intelligence: A Critical Defense Tool for Your Security Operations

Threat intelligence and information sharing is raising a new kind of awareness around new methods of attack, especially when in combination with your SIEM.

The post Threat Intelligence: A Critical Defense Tool for Your Security Operations appeared first on Recorded Future.

     

As attack methods continue to evolve and multiply, the only chance of staying a step ahead is enabling your security operations center (SOC) with the most powerful toolset possible. As the complexity of security has increased, a wide array of products have come to the forefront in an effort to prevent the battle for safety from becoming a losing one.
Recently, though, one tactic in particular has proven extremely effective, primarily because it does its job before an impactful security event actually takes place: threat intelligence.
It’s no secret that SOC analysts are becoming buried in more security data on a daily basis, and without the right tools, identifying critical security insights and making the right recommendations in an efficient or effective manner is next to impossible. Threat intelligence allows businesses to both avert and mitigate developing security threats before they actually make a negative impact.
The concept of threat intelligence has been on the rise in recent years. As TechCrunch reported, the practice area has brought forth a number of initiatives led by researchers and security vendors who are working together to collaborate, share security information, and protect customers, such as the Cyber Threat Alliance.
The government is getting involved, too. The Cybersecurity Information Sharing Act (CISA), was enacted in 2015 as a way to make threat intelligence sharing easily accessible to businesses.
Ultimately, the development of threat intelligence is resulting in a multitude of platforms and standards that are aimed at helping businesses and federal organizations collect, aggregate, and use cyber threat intelligence in common with others. The results are reducing the lifespans of new attacks and putting pressure on malicious actors, making it more difficult to continue operating.
Threat intelligence and information sharing is raising a new kind of proactive awareness around new methods of attack, as well as in-progress data breaches as they happen, providing a way to avoid significant security events from affecting more targets.
The Preemptive Power of Recorded Future, Combined With Splunk
So, what kinds of tools are available for harnessing the power of threat intelligence to put organizations in a better position of defense and assist security operations personnel?
There are quite a few, each with their own benefits, but this post will focus on using threat intelligence in combination with your security information and event management (SIEM) solution. In this case, Recorded Future for Splunk.

By integrating Recorded Future with Splunk, security teams can visualize the content generated by Recorded Future, enhancing their overall understanding of the security posture of the environment. Let’s look at some examples.
Make fast, informed security determinations.
Security teams are tasked with parsing through a myriad of events and alerts on a daily basis. When Recorded Future and Splunk work together, the significance of potential security events becomes remarkably clearer via rich context. Armed with threat intelligence, analysts are able to more quickly identify irrelevant or false events and gain greater insight into legitimate incidents.
Identify critical incidents that could be easily overlooked.
Recorded Future provides the means to apply specific indicators consistent with security needs to generate accurate event correlation and detection. Indicators are identified with increased risks through web reporting, threat lists, and proprietary methods unique to Recorded Future.
Access threat insights beyond what you can see on your network.
Recorded Future for Splunk also delivers the capacity to detect incidents proactively as they’re originated or reported beyond a network. Risks can be monitored and alerted on according to IP address ranges, domains, and companies. As alerts are triggered, SOC analysts will receive detailed notifications that include origin, source links, and cached access to content.
The August Schell Take on Using Machine Learning for Threat Intelligence
August Schell Enterprises is a big proponent of using machine data to generate threat intelligence and enable sharing, and frequently works with both federal and commercial customers to help them reap its value. Recorded Future has been proven a highly effective product for real-time threat intelligence security, particularly when paired with Splunk, and August Schell has made a concerted effort to closely partner with both vendors in an effort to maximize the positive impacts of their solutions for its customers.
Machine learning brings great potential in enhancing security defenses, but it also requires a powerful solution set for revealing insights and giving rise to action; this is what Recorded Future for Splunk is able to achieve.
If your organization is interested in learning more about how Recorded Future for Splunk can enhance your security program, request a demo or reach out to an August Schell specialist.

Ron Flax
Ron Flax is Vice President and Chief Technology Officer at August Schell, where he leads the way in learning about new technology products, leveraging those in the business, and educating employees, partners, and customers on the interesting and unique ways these technologies can be applied to solving problems.

The post Threat Intelligence: A Critical Defense Tool for Your Security Operations appeared first on Recorded Future.
     
Go to Source
Author: Ron Flax

Powered by WPeMatico

Fatboy Ransomware-as-a-Service Emerges on Russian-Language Forum

Fatboy Ransomware-as-a-Service Emerges on Russian-Language Forum

Recently a member of a top-tier Russian cyber criminal forum posted an advertisement for “Fatboy,” a new ransomware-as-a-service (RaaS) product. Learn more.

The post Fatboy Ransomware-as-a-Service Emerges on Russian-Language Forum appeared first on Recorded Future.

     

On March 24, 2017, a member of a top-tier Russian cyber criminal forum posted an advertisement for “Fatboy,” a new ransomware-as-a-service (RaaS) product.
The advertiser, operating under the username “polnowz,” describes Fatboy as a partnership, offering support and guidance through Jabber. While the RaaS has not yet received any endorsements or feedback from the hacking community, on March 26, “ilcn,” a reputable member of the forum, offered to assist polnowz with translation in the product.

Query results for “Fatboy Ransomware” in Recorded Future show posts by polnowz and ilcn about Karmen.
Background
The Fatboy ransomware is dynamic in the way it targets its victims; the amount of ransom demanded is determined by the victim’s location.
According to polnowz, Fatboy uses a payment scheme based on The Economist’s Big Mac Index (cited as the “McDonald’s Index” in the product description), meaning that victims in areas with a higher cost of living will be charged more to have their data decrypted.

The Economist invented the Big Mac Index in 1986 as a tool for explaining exchange-rate theory.
Purchasers of the Fatboy RaaS partner directly with the author of the malware and not through a third-party vendor. Potential partners also receive payment instantly when a victim pays their ransom, adding another level of transparency to this partnership.

Since February 7, 2017, the author of the Fatboy RaaS has purportedly earned at least $5,321 USD from their own ransomware campaigns using this product.

A computer infected with the Fatboy malware will display the above message, explaining that the user’s files have been encrypted, stating the ransom amount, and warning the user against interfering with the ransomware.
The following is the description of Fatboy RaaS by polnowz:
We invite you to take part in a partnership for the monetization of downloads with help of the Fatboy encryption software. Limited partnership.
Product Description
Base load 15.6 kB, written in C++
Active cryptolocker development and support
Works on all Windows OS x86/x64
Multi-language user interface (12 languages)
Encrypts every file with AES-256 with individual keys, then, all keys are encrypted with RSA-2048
Comfortable partner panel with full statistics by country and time
Detailed information on each individual client is in the partner panel
Scans all disks and network folders
New Bitcoin wallet number for each client
Software deletes after payment
Instant transfer of funds to the partner after the victim pays for decryption
Automatic file decryption after payment
Support for more than 5000 file extensions
Automatic price adjustment depending on the country’s living standards (McDonald’s Index)
Extended help with step-by-step instructions for payment
Partner Details
Support and guidance for partners through Jabber (OTR)
Conversion level of partner traffic makes up 3-15% of overall downloads
Partner program requires access to the admin panel
Requirements
Reasonable quality installs in reliable volumes
Doesn’t work in the Commonwealth of Independent States
There are no other bundles or ways to download

Conclusion
The level of transparency in the Fatboy RaaS partnership may be a strategy to quickly gain the trust of potential buyers. Additionally, the automatic price adjustment feature shows an interest in customizing malware based on the targeted victim.
Organizations should be aware of the adaptability of Fatboy, as well as other ransomware products, and continuously update their cyber security strategies as these threats evolve.
The post Fatboy Ransomware-as-a-Service Emerges on Russian-Language Forum appeared first on Recorded Future.
     
Go to Source
Author: Diana Granger

Powered by WPeMatico

WMImplant – A WMI Based Agentless Post-Exploitation RAT Developed in PowerShell

WMImplant – A WMI Based Agentless Post-Exploitation RAT Developed in PowerShell

Just over one year ago (November 2015), I released WMIOps, a PowerShell
script that enables a user to carry out different actions via Windows
Management Instrumentation (WMI) on the local machine or a remote
machine. WMIOps can:

  • Start or stop a process.
  • Return a list of all running
    processes.
  • Power off, reboot, or log users off the targeted
    system.
  • Get a listing of all files within a directory.
  • Read a file’s contents.
  • …and more.

As I continued to develop WMIOps and use it during Mandiant
Red Team Operations
, I realized that it has some of the same
capabilities that are in Remote Access Tools (RATs). WMIOps’s
capabilities were in a state of disparate functions, but if I wove
what existed along with new functionality, I could create a RAT. After
months of development and internal testing, I’m happy to publicly
release WMImplant.

WMImplant leverages WMI for the command and control channel, the
means for executing actions (gathering data, issuing commands, etc.)
on the targeted system, and data storage. It is designed to run both
interactively and non-interactively. When using WMImplant
interactively, it’s designed to have a menu of commands reminiscent of
Meterpreter, as shown in Figure 1.

Figure 1: WMImplant main menu

Data Storage and Device Guard

After spending some time developing WMImplant, I ran into issues
storing data on systems that used Device
Guard
, a Microsoft security feature added in Windows 10 and Server
2016. Even though this feature and these operating systems are not
widely deployed today, I wanted WMImplant to support these systems
since I expect Device Guard protected systems to become more common,
especially at security-conscious organizations. Device Guard helps
protect systems by employing (among other capabilities not detailed here):

  1. Code Integrity Policies – When deploying Device Guard,
    administrators will create a code integrity policy (CIP) that
    explicitly defines what is allowed to run on the protected system.
    This granularity can range from file hash, file name, publisher,
    both file name and publisher, and much more. Administrators can
    create the CIP from a gold-imaged computer. Administrators can
    further enhance their CIP by preventing applications that provide
    attackers the ability to bypass Device Guard’s protections from
    running. Finally, administrators can use Group Policy Objects (GPO)
    to enable Device Guard, preventing executables or select scripts
    from running unless explicitly allowed, per the CIP.
  2. PowerShell Constrained Language Mode – Device Guard auto-enrolls
    PowerShell into ConstrainedLanguage
    mode. Constrained Language mode restricts the cmdlets and data types
    that are allowed to run in PowerShell. In this mode, .NET methods
    are completely blocked unless they are an allowed data type.

On a Device Guard protected system, attackers cannot run custom
executables, and the available PowerShell cmdlets are severely
restricted. For example, simple functionality such as base64 encoding
a string is not permitted within Constrained Language mode, as shown
in Figure 2.

Figure 2: PowerShell Constrained Language mode
blocking base64 encoding

At first, I designed WMImplant to use the Windows Registry for data
storage, as described in Matt
Graeber’s WMI research
. However, after discussing using the
Windows Registry for data storage with Matt Dunwoody (a Mandiant
coworker), he suggested, “Why not also use WMI itself for storage?”

This conversation led me to research using WMI for data storage. I
found a proof-of-concept for creating custom WMI properties (Figure 3)
in FireEye’s report on WMI
Offense, Defense, and Forensics
.

Figure 3: Sample code from FireEye report on WMI
Offense, Defense, and Forensics

However, after testing this code on a Device Guard protected system,
I discovered that this wasn’t permitted within Constrained Language
mode, as shown in Figure 4.

Figure 4: Constrained Language mode blocking WMI
property creation

After some additional research, I found that within Constrained
Language mode, users are able to create custom WMI classes. But, as
evidenced by Figure 4, WMI property creation is not allowed, so this
wouldn’t work for data storage. Therefore, my next thought was to
store data in an existing WMI property. In order to leverage an
existing WMI property, a few conditions would need to be present:

  1. The property needs to be of type string.
  2. The property
    needs to be writable.
  3. The property needs to accept an
    arbitrary length of data.
  4. Modifications to the property
    need to not blue screen or degrade use of the targeted system.
  5. Most importantly, the property needs to be writable within
    Constrained Language mode.

I modified an existing PowerShell script to enumerate all WMI
classes, find the properties of each class, check if each property is
a string type, and determine if it is writable (the script is available here).

The script identified a list of candidate WMI properties, but for
one reason or another, modifications to those that I initially tested
resulted in “general failures”. Then, I came across a class I have not
previously used: Win32_OSRecoveryConfiguration. This class has
a property named “DebugFilePath”, which is the file path where Windows
will place a memory dump after a computer failure, as shown in Figure 5.

Figure 5: Win32_OSRecoveryConfiguration’s
DebugFilePath property

The DebugFilePath appears to only accept a file path, and the
property should be limited to the length of a valid Windows paths (260
characters by default or 32k with LongPathsEnabled). In testing,
however, I discovered that I could write an arbitrary string to the
DebugFilePath property within Constrained Language mode without
adversely affecting the targeted system. The final test was to
determine how much data could be placed in the DebugFilePath property.

Figure 6: Data storage test within DebugFilePath

Figure 6 shows that the DebugFilePath property can store over 57
megabytes of data. This satisfied the data storage requirement for
WMImplant, and future testing showed that the DebugFilePath property
could store more than 250 megabytes of data. Additionally, using the
DebugFilePath WMI property for data storage provides the side-benefits
that it is easily retrievable and modifiable remotely.

This discovery shaped WMImplant’s command and control communications
methodology. For commands issued by WMImplant that require data
storage, the communication process is as follows:

  1. Remotely query and obtain the original value for
    Win32_OSRecoveryConfiguration’s DebugFilePath property.
  2. Use
    WMImplant to execute a command on the targeted system (such as
    ifconfig), encode the output, and store the encoded results in the
    DebugFilePath property.
  3. Remotely query the targeted
    system’s DebugFilePath over WMI to receive the encoded results.
  4. Decode the results and display them to the console.
  5. Set
    the DebugFilePath property on the targeted system back to its
    original value.

This methodology for command and control communications minimizes
the amount of time that the WMI property is modified from its original state.

WMImplant Usage

I’ve developed WMImplant for both interactive and non-interactive
use. Users also have the ability to change the user account that is
authenticating to the targeted machine. As shown in Figure 7, users
can issue the “change_user” command, provide the username and password
to use, and then all future commands through WMImplant will
authenticate with the provided credentials.

Figure 7: Changing the current user context
within WMImplant

The easiest way to use WMImplant is interactively; however, that
isn’t always possible. RATs such as Meterpreter or Cobalt Strike’s
Beacon allow users to load and execute PowerShell scripts, but both of
those tools require non-interactive use. That is, the tools accept a
command to run, execute it, and return the results. They do not allow
the user to interact with the command while running, however.
WMImplant includes a built-in command-line generating feature
specifically for this use case. To generate a command-line, start
WMImplant and specify the “gen_cli” command.

After issuing the “gen_cli” command, the user will be presented with
the normal WMImplant menu and asked for the command to be run.
WMImplant will then ask for any required information for the command
specified. Once the user has provided everything that’s required,
WMImplant will display the command-line command to run in a
non-interactive manner, as shown in Figure 8.

Figure 8: “gen_cli” output

At this point, the user can load WMImplant within the RAT of choice,
and copy and paste the command to run WMImplant non-interactively.

Another of WMImplant’s capabilities is the ability to run a
PowerShell script on a remote machine and receive script output. This
is performed through a multi-step process:

  1. The attacking system queries the targeted system’s
    DebugFilePath property to obtain its original value.
  2. The
    attacking system reads in the specified PowerShell script, encodes
    it, and stores it in the targeted system’s DebugFilePath
    property.
  3. WMI spawns a PowerShell process on the targeted
    system that reads the DebugFilePath property, and decodes the
    PowerShell script.
  4. The PowerShell process runs the
    user-specified function and stores the function output in a
    variable.
  5. The data in the variable is encoded and stored in
    the DebugFilePath property, and the PowerShell process exits.
  6. The attacking system makes an additional WMI query for the
    DebugFilePath value (currently storing the encoded data), decodes
    the data, and displays its contents to the console.
  7. The
    attacking system replaces the encoded data with the original
    DebugFilePath property contents on the targeted system over
    WMI.

This multi-step process is demonstrated in Figure 9.

Figure 9: Remote PowerShell execution

While I’ve only talked about a limited number of WMImplant’s
features, others include:

  • Setting/removing the “UseLogonCredential” Windows Registry
    value to enable credential caching.
  • Uploading/downloading
    files.
  • Enabling/disabling Windows Remote Management (WinRM)
    to remotely connect to and issue commands on a system using
    PowerShell.
  • Identifying users who have logged in to the
    targeted system.
  • Listing files by directory.
  • Reading file contents.
  • …and more.

I hope that WMImplant can help others as it has helped us on
multiple assessments. If you notice any bugs, please let me know and
I’ll be happy to get a fix pushed!

WMImplant can be downloaded here.

Thanks

I want to state that I wouldn’t have been inspired to work on this
without the previous
work
of Matt Graeber, Willi Ballenthin, and Claudiu Teodorescu.
Their work gave me a lot of great ideas that I was able to build upon
when developing WMImplant.

Just over one year ago (November 2015), I released WMIOps, a PowerShell
script that enables a user to carry out different actions via Windows
Management Instrumentation (WMI) on the local machine or a remote
machine. WMIOps can:
Start or stop a process. Return a list of all running
processes. Power off, reboot, or log users off the targeted
system. Get a listing of all files within a directory.
Read a file’s contents. …and more. As I continued to develop WMIOps and use it during Mandiant
Red Team Operations, I realized that it has some of the same
capabilities that are in Remote Access Tools (RATs). WMIOps’s
capabilities were in a state of disparate functions, but if I wove
what existed along with new functionality, I could create a RAT. After
months of development and internal testing, I’m happy to publicly
release WMImplant.
WMImplant leverages WMI for the command and control channel, the
means for executing actions (gathering data, issuing commands, etc.)
on the targeted system, and data storage. It is designed to run both
interactively and non-interactively. When using WMImplant
interactively, it’s designed to have a menu of commands reminiscent of
Meterpreter, as shown in Figure 1.

Figure 1: WMImplant main menu
Data Storage and Device Guard
After spending some time developing WMImplant, I ran into issues
storing data on systems that used Device
Guard, a Microsoft security feature added in Windows 10 and Server
2016. Even though this feature and these operating systems are not
widely deployed today, I wanted WMImplant to support these systems
since I expect Device Guard protected systems to become more common,
especially at security-conscious organizations. Device Guard helps
protect systems by employing (among other capabilities not detailed here):
Code Integrity Policies – When deploying Device Guard,
administrators will create a code integrity policy (CIP) that
explicitly defines what is allowed to run on the protected system.
This granularity can range from file hash, file name, publisher,
both file name and publisher, and much more. Administrators can
create the CIP from a gold-imaged computer. Administrators can
further enhance their CIP by preventing applications that provide
attackers the ability to bypass Device Guard’s protections from
running. Finally, administrators can use Group Policy Objects (GPO)
to enable Device Guard, preventing executables or select scripts
from running unless explicitly allowed, per the CIP.
PowerShell Constrained Language Mode – Device Guard auto-enrolls
PowerShell into ConstrainedLanguage
mode. Constrained Language mode restricts the cmdlets and data types
that are allowed to run in PowerShell. In this mode, .NET methods
are completely blocked unless they are an allowed data type. On a Device Guard protected system, attackers cannot run custom
executables, and the available PowerShell cmdlets are severely
restricted. For example, simple functionality such as base64 encoding
a string is not permitted within Constrained Language mode, as shown
in Figure 2.

Figure 2: PowerShell Constrained Language mode
blocking base64 encoding
At first, I designed WMImplant to use the Windows Registry for data
storage, as described in Matt
Graeber’s WMI research. However, after discussing using the
Windows Registry for data storage with Matt Dunwoody (a Mandiant
coworker), he suggested, “Why not also use WMI itself for storage?”
This conversation led me to research using WMI for data storage. I
found a proof-of-concept for creating custom WMI properties (Figure 3)
in FireEye’s report on WMI
Offense, Defense, and Forensics.

Figure 3: Sample code from FireEye report on WMI
Offense, Defense, and Forensics
However, after testing this code on a Device Guard protected system,
I discovered that this wasn’t permitted within Constrained Language
mode, as shown in Figure 4.

Figure 4: Constrained Language mode blocking WMI
property creation
After some additional research, I found that within Constrained
Language mode, users are able to create custom WMI classes. But, as
evidenced by Figure 4, WMI property creation is not allowed, so this
wouldn’t work for data storage. Therefore, my next thought was to
store data in an existing WMI property. In order to leverage an
existing WMI property, a few conditions would need to be present:
The property needs to be of type string. The property
needs to be writable. The property needs to accept an
arbitrary length of data. Modifications to the property
need to not blue screen or degrade use of the targeted system.
Most importantly, the property needs to be writable within
Constrained Language mode. I modified an existing PowerShell script to enumerate all WMI
classes, find the properties of each class, check if each property is
a string type, and determine if it is writable (the script is available here).
The script identified a list of candidate WMI properties, but for
one reason or another, modifications to those that I initially tested
resulted in “general failures”. Then, I came across a class I have not
previously used: Win32_OSRecoveryConfiguration. This class has
a property named “DebugFilePath”, which is the file path where Windows
will place a memory dump after a computer failure, as shown in Figure 5.

Figure 5: Win32_OSRecoveryConfiguration’s
DebugFilePath property
The DebugFilePath appears to only accept a file path, and the
property should be limited to the length of a valid Windows paths (260
characters by default or 32k with LongPathsEnabled). In testing,
however, I discovered that I could write an arbitrary string to the
DebugFilePath property within Constrained Language mode without
adversely affecting the targeted system. The final test was to
determine how much data could be placed in the DebugFilePath property.

Figure 6: Data storage test within DebugFilePath
Figure 6 shows that the DebugFilePath property can store over 57
megabytes of data. This satisfied the data storage requirement for
WMImplant, and future testing showed that the DebugFilePath property
could store more than 250 megabytes of data. Additionally, using the
DebugFilePath WMI property for data storage provides the side-benefits
that it is easily retrievable and modifiable remotely.
This discovery shaped WMImplant’s command and control communications
methodology. For commands issued by WMImplant that require data
storage, the communication process is as follows:
Remotely query and obtain the original value for
Win32_OSRecoveryConfiguration’s DebugFilePath property. Use
WMImplant to execute a command on the targeted system (such as
ifconfig), encode the output, and store the encoded results in the
DebugFilePath property. Remotely query the targeted
system’s DebugFilePath over WMI to receive the encoded results.
Decode the results and display them to the console. Set
the DebugFilePath property on the targeted system back to its
original value. This methodology for command and control communications minimizes
the amount of time that the WMI property is modified from its original state.
WMImplant Usage
I’ve developed WMImplant for both interactive and non-interactive
use. Users also have the ability to change the user account that is
authenticating to the targeted machine. As shown in Figure 7, users
can issue the “change_user” command, provide the username and password
to use, and then all future commands through WMImplant will
authenticate with the provided credentials.

Figure 7: Changing the current user context
within WMImplant
The easiest way to use WMImplant is interactively; however, that
isn’t always possible. RATs such as Meterpreter or Cobalt Strike’s
Beacon allow users to load and execute PowerShell scripts, but both of
those tools require non-interactive use. That is, the tools accept a
command to run, execute it, and return the results. They do not allow
the user to interact with the command while running, however.
WMImplant includes a built-in command-line generating feature
specifically for this use case. To generate a command-line, start
WMImplant and specify the “gen_cli” command.
After issuing the “gen_cli” command, the user will be presented with
the normal WMImplant menu and asked for the command to be run.
WMImplant will then ask for any required information for the command
specified. Once the user has provided everything that’s required,
WMImplant will display the command-line command to run in a
non-interactive manner, as shown in Figure 8.

Figure 8: “gen_cli” output
At this point, the user can load WMImplant within the RAT of choice,
and copy and paste the command to run WMImplant non-interactively.
Another of WMImplant’s capabilities is the ability to run a
PowerShell script on a remote machine and receive script output. This
is performed through a multi-step process:
The attacking system queries the targeted system’s
DebugFilePath property to obtain its original value. The
attacking system reads in the specified PowerShell script, encodes
it, and stores it in the targeted system’s DebugFilePath
property. WMI spawns a PowerShell process on the targeted
system that reads the DebugFilePath property, and decodes the
PowerShell script. The PowerShell process runs the
user-specified function and stores the function output in a
variable. The data in the variable is encoded and stored in
the DebugFilePath property, and the PowerShell process exits.
The attacking system makes an additional WMI query for the
DebugFilePath value (currently storing the encoded data), decodes
the data, and displays its contents to the console. The
attacking system replaces the encoded data with the original
DebugFilePath property contents on the targeted system over
WMI. This multi-step process is demonstrated in Figure 9.

Figure 9: Remote PowerShell execution
While I’ve only talked about a limited number of WMImplant’s
features, others include:
Setting/removing the “UseLogonCredential” Windows Registry
value to enable credential caching. Uploading/downloading
files. Enabling/disabling Windows Remote Management (WinRM)
to remotely connect to and issue commands on a system using
PowerShell. Identifying users who have logged in to the
targeted system. Listing files by directory.
Reading file contents. …and more. I hope that WMImplant can help others as it has helped us on
multiple assessments. If you notice any bugs, please let me know and
I’ll be happy to get a fix pushed!
WMImplant can be downloaded here.
Thanks
I want to state that I wouldn’t have been inspired to work on this
without the previous
work of Matt Graeber, Willi Ballenthin, and Claudiu Teodorescu.
Their work gave me a lot of great ideas that I was able to build upon
when developing WMImplant.
Go to Source
Author: Christopher Truncer

Powered by WPeMatico

APT29 Domain Fronting With TOR

APT29 Domain Fronting With TOR

Mandiant has observed Russian nation-state attackers APT29 employing
domain fronting techniques for stealthy backdoor access to victim
environments for at least two years. There has been considerable
discussion about domain fronting following the release of a paper
detailing these techniques
. Domain fronting provides outbound
network connections that are indistinguishable from legitimate
requests for popular websites.

APT29 has used The Onion Router (TOR) and the TOR domain fronting
plugin meek to create a hidden, encrypted network tunnel that appeared
to connect to Google services over TLS. This tunnel provided the
attacker remote access to the host system using the Terminal Services
(TS), NetBIOS, and Server Message Block (SMB) services, while
appearing to be traffic to legitimate websites. The attackers also
leveraged a common Windows exploit to access a privileged command
shell without authenticating.

We first discussed APT29’s use of these techniques as part of our
“No Easy Breach” talk at DerbyCon 6.0. For additional details on how
we first identified this backdoor, and the epic investigation it was
part of, see the slides
and presentation.

Domain Fronting Overview

The Onion
Router (TOR)
is a network of proxy nodes that attempts to
provide anonymity to users accessing the Internet. TOR transfers
internet traffic through a series of proxy points on the Internet,
with each node knowing only the previous and next node in the path.
This proxy network, combined with pervasive encryption, makes tracking
the source of TOR Internet activity extremely difficult. A TOR client
can also use the TOR network to host services that are not accessible
from the open Internet. These services are commonly used to host “dark
web” sites such as the defunct Silk Road.

Typically network analysts can identify normal TOR traffic through
signature analysis or the identification of communication with TOR
infrastructure. Meek
is a publicly available obfuscation plugin for TOR and an
implementation of the domain fronting technique. To hide TOR traffic,
meek takes advantage of the way that Google and other Internet content
delivery networks (CDNs) route traffic. CDNs often route traffic from
IP addresses associated with one service to servers associated with
another service hosted on the same network. By hosting a meek
reflection server in one of these CDNs, meek can hide TOR traffic in
legitimate HTTPS connections to well-known services.

Meek obfuscates traffic in several stages. First, it encodes TOR
traffic into HTTP specifying the host name of the reflection server
(for example, the default server meek-reflect.appspot.com). It then
wraps that HTTP traffic in a legitimate TLS connection to a server
hosted in the same CDN cloud as the reflection server (in this
example, Google). When the CDN server receives the connection, it
decrypts the TLS traffic, identifies the hostname specified in the
HTTP header and redirects the traffic to the reflection server. The
reflection server then reconstructs the original TOR traffic from the
HTTP stream and sends the traffic to the TOR network, which routes it
to its destination. This process creates an outbound network
connection that appears to contain normal HTTPS POST requests for
google.com on a Google-owned IP address,
while discretely passing the traffic through the reflection server to
the TOR network. Meek can also use the TLS service and cipher suites
used by Firefox to further obfuscate traffic. Differentiating this
traffic from legitimate connections is extremely difficult, and
encryption of both on the initial TLS connection and the TOR traffic
makes meaningful analysis of the traffic impossible. Note: Google
suspended the reflection server meek-reflect.appspot.com, but other
servers, in the Google cloud or other supported CDNs, can fulfill the
same function.

Figure 1 displays the traffic flow when using meek.

Figure 1: Meek traffic flow

Backdoor Overview

Mandiant discovered that APT29 enabled a TOR hidden service that
forwarded traffic from the TOR client to local ports 139, 445 and 3389
(NetBIOS, SMB and TS, respectively). This provided the attackers full
remote access to the system from outside of the local network using
the hidden TOR (.onion) address of the system.

The attackers created the following files and directories during the
installation and execution of the backdoor:

  • C:Program
    Files(x86)GooglegoogleService.exe
  • C:Program
    Files(x86)GoogleGoogleUpdate.exe
  • C:Program Files(x86)Googlecore
  • C:Program Files(x86)Googledata
  • C:Program Files(x86)Googledata0
  • C:Program
    Files(x86)Googledata0hostname
  • C:Program
    Files(x86)Googledata0private_key
  • C:Program
    Files(x86)Googledebug.log
  • C:Program Files(x86)Googlelock
  • C:Program
    Files(x86)Googlecached-certs
  • C:Program
    Files(x86)Googlecached-microdescs
  • C:Program
    Files(x86)Googlecached-microdescs.new
  • C:Program
    Files(x86)Googlecached-microdescs-consensus
  • C:Program Files(x86)Googlestate
  • C:Program
    Files(x86)Googlestart.ps1
  • C:Program
    Files(x86)Googleinstall.bat

The file googleService.exe is the primary
TOR executable, responsible for establishing and maintaining encrypted
proxy connections. GoogleUpdate.exe is the
meek-client plugin, which obfuscates the TOR connection. These files
are publicly available and have the following hashes:

Filename                     SHA256

googleService.exe    
fe744a5b2d07de396a8b3fe97155fc64e350b76d88db36c619cd941279987dc5
GoogleUpdate.exe      2f39dee2ee608e39917cc022d9aae399959e967a2dd70d83b81785a98bd9ed36

The file C:Program Files
(x86)Googlecore
contains configuration information for the
TOR service googleService.exe. The service
was configured to:

  • Communicate on ports 1, 80 and 443
  • Bridge traffic
    using the meek plugin to https://meek-reflect.appspot.com and obfuscate
    HTTPS and DNS requests to appear destined for www.google.com
  • Forward traffic from ports
    62304, 62305 and 62306 to ports 3389, 139 and 445, respectively

Figure 2 displays the contents of the TOR configuration file core.

Figure 2: Contents of TOR configuration file
“C:Program Files(x86)Googlecore”

The C:Program Files
(x86)Googledata0hostname
” file contained a single line
with the TOR hostname for the system. This hostname was a
pseudorandomly-generated 16 character alpha-numeric name, with the
top-level domain (TLD) .onion.

The C:Program
Files(x86)Googledata0private_key
file contained the TOR
client RSA private key. Figure 3 displays the redacted contents of a
sample private_key file.

Figure 3: Redacted contents of sample private_key

The attackers used the scripts start.ps1
and install.bat to install the TOR service.
After installation, the attackers deleted these scripts from the
system. Additional files in the directory C:Program Files(x86)Google contained cached
data and logs from the operation of TOR.

Additional information on increasing visibility into PowerShell
activity through enhanced logging is available here.

Installation and Persistence

The attacker executed the PowerShell script C:Program Files(x86)Googlestart.ps1 to
install the TOR services and implement the “Sticky Keys” exploit. This
script was deleted after execution, and was not recovered.

By replacing the “Sticky Keys” binary, C:WindowsSystem32sethc.exe, with the Windows
Command Processor cmd.exe, the attackers
then accessed a privileged Windows console session without
authenticating to the system. “Sticky Keys” is an accessibility
feature that allows users to activate Windows modifier keys without
pressing more than one key at a time. Pressing the shift key five
times activates “Sticky Keys” and executes sethc.exe, which, when replaced with cmd.exe, opens a System-level command shell. From
this shell, the attackers can execute arbitrary Windows commands,
including adding or modifying accounts on the system, even from the
logon screen (pre-authentication). By tunneling RDP traffic to the
system, the attackers could gain both persistent access and privilege
escalation using this simple and well-known exploit.

The installation script start.ps1 created
a Windows service named Google Update to
maintain persistence after a system reboot. Table 1 contains registry
details for the “Google Update” service.

Table 1: Registry details for the TOR Google
Update Windows service

The script also modified the Terminal Server registry values fSingleSessionPerUser to allow multiple
simultaneous Windows sessions using the same account, and fDenyTSConnections to allow Terminal Services
connections. Table 2 shows the modified values for these registry keys.

Table 2: Registry modifications performed by start.ps1

Conclusion

APT29 adopted domain fronting long before these techniques were
widely known. By employing a publicly available implementation, they
were able to hide their network traffic, with minimal research or
development, and with tools that are difficult to attribute. Detecting
this activity on the network requires visibility into TLS connections
and effective network signatures. However, when dealing with advanced
threat groups who rapidly develop capabilities and invest in hiding
network traffic, effective endpoint visibility is vital. Monitoring
for potentially interesting events and attacker methodologies, like
lateral movement and new persistence creation, can allow defenders to
identify these stealthy methodologies.

Mandiant has observed Russian nation-state attackers APT29 employing
domain fronting techniques for stealthy backdoor access to victim
environments for at least two years. There has been considerable
discussion about domain fronting following the release of a paper
detailing these techniques. Domain fronting provides outbound
network connections that are indistinguishable from legitimate
requests for popular websites.
APT29 has used The Onion Router (TOR) and the TOR domain fronting
plugin meek to create a hidden, encrypted network tunnel that appeared
to connect to Google services over TLS. This tunnel provided the
attacker remote access to the host system using the Terminal Services
(TS), NetBIOS, and Server Message Block (SMB) services, while
appearing to be traffic to legitimate websites. The attackers also
leveraged a common Windows exploit to access a privileged command
shell without authenticating.
We first discussed APT29’s use of these techniques as part of our
“No Easy Breach” talk at DerbyCon 6.0. For additional details on how
we first identified this backdoor, and the epic investigation it was
part of, see the slides
and presentation.
Domain Fronting Overview

The Onion
Router (TOR) is a network of proxy nodes that attempts to
provide anonymity to users accessing the Internet. TOR transfers
internet traffic through a series of proxy points on the Internet,
with each node knowing only the previous and next node in the path.
This proxy network, combined with pervasive encryption, makes tracking
the source of TOR Internet activity extremely difficult. A TOR client
can also use the TOR network to host services that are not accessible
from the open Internet. These services are commonly used to host “dark
web” sites such as the defunct Silk Road.
Typically network analysts can identify normal TOR traffic through
signature analysis or the identification of communication with TOR
infrastructure. Meek
is a publicly available obfuscation plugin for TOR and an
implementation of the domain fronting technique. To hide TOR traffic,
meek takes advantage of the way that Google and other Internet content
delivery networks (CDNs) route traffic. CDNs often route traffic from
IP addresses associated with one service to servers associated with
another service hosted on the same network. By hosting a meek
reflection server in one of these CDNs, meek can hide TOR traffic in
legitimate HTTPS connections to well-known services.
Meek obfuscates traffic in several stages. First, it encodes TOR
traffic into HTTP specifying the host name of the reflection server
(for example, the default server meek-reflect.appspot.com). It then
wraps that HTTP traffic in a legitimate TLS connection to a server
hosted in the same CDN cloud as the reflection server (in this
example, Google). When the CDN server receives the connection, it
decrypts the TLS traffic, identifies the hostname specified in the
HTTP header and redirects the traffic to the reflection server. The
reflection server then reconstructs the original TOR traffic from the
HTTP stream and sends the traffic to the TOR network, which routes it
to its destination. This process creates an outbound network
connection that appears to contain normal HTTPS POST requests for
google.com on a Google-owned IP address,
while discretely passing the traffic through the reflection server to
the TOR network. Meek can also use the TLS service and cipher suites
used by Firefox to further obfuscate traffic. Differentiating this
traffic from legitimate connections is extremely difficult, and
encryption of both on the initial TLS connection and the TOR traffic
makes meaningful analysis of the traffic impossible. Note: Google
suspended the reflection server meek-reflect.appspot.com, but other
servers, in the Google cloud or other supported CDNs, can fulfill the
same function.
Figure 1 displays the traffic flow when using meek.

Figure 1: Meek traffic flow
Backdoor Overview
Mandiant discovered that APT29 enabled a TOR hidden service that
forwarded traffic from the TOR client to local ports 139, 445 and 3389
(NetBIOS, SMB and TS, respectively). This provided the attackers full
remote access to the system from outside of the local network using
the hidden TOR (.onion) address of the system.
The attackers created the following files and directories during the
installation and execution of the backdoor:

C:Program
Files(x86)GooglegoogleService.exe
C:Program
Files(x86)GoogleGoogleUpdate.exe
C:Program Files(x86)Googlecore
C:Program Files(x86)Googledata
C:Program Files(x86)Googledata0
C:Program
Files(x86)Googledata0hostname
C:Program
Files(x86)Googledata0private_key
C:Program
Files(x86)Googledebug.log
C:Program Files(x86)Googlelock
C:Program
Files(x86)Googlecached-certs
C:Program
Files(x86)Googlecached-microdescs
C:Program
Files(x86)Googlecached-microdescs.new
C:Program
Files(x86)Googlecached-microdescs-consensus
C:Program Files(x86)Googlestate
C:Program
Files(x86)Googlestart.ps1
C:Program
Files(x86)Googleinstall.bat The file googleService.exe is the primary
TOR executable, responsible for establishing and maintaining encrypted
proxy connections. GoogleUpdate.exe is the
meek-client plugin, which obfuscates the TOR connection. These files
are publicly available and have the following hashes:
Filename                     SHA256

googleService.exe    
fe744a5b2d07de396a8b3fe97155fc64e350b76d88db36c619cd941279987dc5
GoogleUpdate.exe      2f39dee2ee608e39917cc022d9aae399959e967a2dd70d83b81785a98bd9ed36
The file C:Program Files
(x86)Googlecore contains configuration information for the
TOR service googleService.exe. The service
was configured to:
Communicate on ports 1, 80 and 443 Bridge traffic
using the meek plugin to https://meek-reflect.appspot.com and obfuscate
HTTPS and DNS requests to appear destined for www.google.com Forward traffic from ports
62304, 62305 and 62306 to ports 3389, 139 and 445, respectively Figure 2 displays the contents of the TOR configuration file core.

Figure 2: Contents of TOR configuration file
“C:Program Files(x86)Googlecore”
The C:Program Files
(x86)Googledata0hostname” file contained a single line
with the TOR hostname for the system. This hostname was a
pseudorandomly-generated 16 character alpha-numeric name, with the
top-level domain (TLD) .onion.
The C:Program
Files(x86)Googledata0private_key file contained the TOR
client RSA private key. Figure 3 displays the redacted contents of a
sample private_key file.

Figure 3: Redacted contents of sample private_key
The attackers used the scripts start.ps1
and install.bat to install the TOR service.
After installation, the attackers deleted these scripts from the
system. Additional files in the directory C:Program Files(x86)Google contained cached
data and logs from the operation of TOR.
Additional information on increasing visibility into PowerShell
activity through enhanced logging is available here.
Installation and Persistence
The attacker executed the PowerShell script C:Program Files(x86)Googlestart.ps1 to
install the TOR services and implement the “Sticky Keys” exploit. This
script was deleted after execution, and was not recovered.
By replacing the “Sticky Keys” binary, C:WindowsSystem32sethc.exe, with the Windows
Command Processor cmd.exe, the attackers
then accessed a privileged Windows console session without
authenticating to the system. “Sticky Keys” is an accessibility
feature that allows users to activate Windows modifier keys without
pressing more than one key at a time. Pressing the shift key five
times activates “Sticky Keys” and executes sethc.exe, which, when replaced with cmd.exe, opens a System-level command shell. From
this shell, the attackers can execute arbitrary Windows commands,
including adding or modifying accounts on the system, even from the
logon screen (pre-authentication). By tunneling RDP traffic to the
system, the attackers could gain both persistent access and privilege
escalation using this simple and well-known exploit.
The installation script start.ps1 created
a Windows service named Google Update to
maintain persistence after a system reboot. Table 1 contains registry
details for the “Google Update” service.

Table 1: Registry details for the TOR Google
Update Windows service
The script also modified the Terminal Server registry values fSingleSessionPerUser to allow multiple
simultaneous Windows sessions using the same account, and fDenyTSConnections to allow Terminal Services
connections. Table 2 shows the modified values for these registry keys.

Table 2: Registry modifications performed by start.ps1

Conclusion
APT29 adopted domain fronting long before these techniques were
widely known. By employing a publicly available implementation, they
were able to hide their network traffic, with minimal research or
development, and with tools that are difficult to attribute. Detecting
this activity on the network requires visibility into TLS connections
and effective network signatures. However, when dealing with advanced
threat groups who rapidly develop capabilities and invest in hiding
network traffic, effective endpoint visibility is vital. Monitoring
for potentially interesting events and attacker methodologies, like
lateral movement and new persistence creation, can allow defenders to
identify these stealthy methodologies.
Go to Source
Author: Matthew Dunwoody

Powered by WPeMatico