At the end of the year, before the Christmas and New Year holidays, the accounting departments of many companies are busy — to put it mildly; especially in countries where the fiscal year is aligned with calendar year. Accountants are busy with financial reporting, planning budgets for the next financial period, and so on. And all that despite the pre-holiday fever where corporate parties are common and colleagues are often not so much in the mood for work. So, of course, cybercriminals can’t ignore this situation: they’re actively sending fake invoices to random employees of companies, in the hope that someone will approve payment in the midst of document flood.

Fraudulent email red-flags

Firstly, the very fact that an email was sent to a random employee, and not directly to the accounting department, should get alarm bells ringing. Criminals usually have no means to obtain the real email addresses of corporate accountants; they use spam mailing databases, consisting primarily of publicly available contacts — so those emails are usually received by employees in HR, PR, technical support, and so on.

Sometimes the senders of the fraudulent emails write that they’ve lost the correct address, or made a typo while writing it down, so they ask to forward the invoice to accounting, or sometimes they don’t bother themselves with explanations. Anyway, this cannot be an excuse for sending an email to a random address. If the invoice is really needed by one of the company’s employees, they would contact the sender themselves, find out the reasons for the delay in delivery and, if necessary, clarify the email address of the accounting department.

Forwarding unexpected emails to colleagues may do more harm than good, for a fraudulent email forwarded by a co-worker is more likely to work. If you forward an invoice to accountants, they may think that you want it to be paid. And in general, an email from an employee of the same company arouses less suspicion than external correspondence.

Secondly, criminals understand that demanding a large amount of money is a bad idea. It’s less likely that such an invoice will be paid without additional enquiries. That’s why they issue invoices for relatively small amounts — insignificant by the standards of a large company.

Thirdly, in the vast majority of cases these kinds of invoices are for correspondence delivery services. Moreover, the accompanying email is written as vaguely as possible so that it’s not always clear whether the invoice was issued directly by the sender of some documents or by the delivery company.

What are the scammers counting on?

As mentioned earlier, criminals count on the year-end’s heavy workload, folks’ general inattention, and non-specialists “help” in forwarding such emails to the accounting department. But the main reason why such schemes work is impunity. By and large, they’re not afraid of legal consequences. Fraudsters register a real company and send out invoices. Legally, this is a service that was paid for but not provided. Yet if someone were to take this to court, they’d probably be found guilty. But will anyone go to court over such trifling amounts of money?

If you try to search the internet by the name of the company that issued the invoice, you’ll probably find a whole host of indignant comments from businesses that were deceived in a similar way. Presumably, from time to time, criminals change the legal entity trifling amounts — closing one company through bankruptcy and opening another one.

How to stay safe?

To begin with, we highly recommend using security solutions with effective anti-spam technologies at the corporate mail gateway level. As a rule, attackers send such emails in large quantities, which allows us timely classify such emails as spam.

In addition, you should inform employees that an email received unexpectedly from someone unknown demanding a payment or personal data is a definitely a suspicious email. And if they want to forward it somewhere, they should send it only to the information security department with the comment “possible fraud”.

Ideally, it’s a good idea to periodically increase employee security awareness; for example, using the automated online Kaspersky Automated Security Awareness Platform. This would allow employees to be prepared for unexpected emails from attackers, be they simple fraudulent spam emails or sophisticated spearphishing.

Kaspersky official blog – ​Read More

The latest episode of the Transatlantic Cable podcast kicks off with news that the EU are the next major governmental body to impose AI regulations, as countries around the world race to stay ahead of the technology. From there, the team discuss news that the BBC were able to make a version of ChatGPT which was capable of writing spam and phishing emails.

From there the team discuss Securelist’s story of the year: Generative A.I and it’s impact on cyber-security.

If you liked what you heard, please consider subscribing.

EU agrees landmark deal on regulation of artificial intelligence
ChatGPT tool could be abused by scammers and hackers
Story of the year: the impact of AI on cybersecurity

Kaspersky official blog – ​Read More

Due to mass password leaks, user forgetfulness, and other problematic areas of modern information security, alternative ways of logging in to systems and corporate software are gaining ground. Besides the familiar authenticator apps and various contactless cards and USB tokens, fingerprint-based biometric authentication is a popular choice — especially since laptop keyboards these days often come with built-in scanners.

This method does seem rather reliable at first glance; however, a recent report by Blackwing Intelligence casts doubt upon this assertion. The authors managed to hack the biometric authentication system and log in to Windows using Windows Hello on Dell Inspiron 15 and Lenovo ThinkPad T14 laptops, as well as using the Microsoft Surface Pro Type Cover with Fingerprint ID keyboard for Surface Pro 8 and Surface Pro X tablets. Let’s have a look at their findings to see whether you should update your cyberdefense strategy.

Anatomy of the hack

First of all, we must note that this was a hardware hack. The researchers had to partially disassemble all three devices, disconnect the sensors from the internal USB bus, and connect them to external USB ports through a Raspberry PI 4 device that carried out a man-in-the-middle attack. The attack exploits the fact that all chips certified for Windows Hello must store the fingerprint database independently, in the on-chip memory. No fingerprints are ever transmitted to the computer itself — only cryptographically signed verdicts such as “User X successfully passed verification”. In addition, the protocol and the chips themselves support storing multiple fingerprints for different users.

The researchers were able to perform the spoofing, although attacks varied for different laptop models. They uploaded onto the chip additional fingerprints, supposedly for a new user, but were able to modify the data exchange with the computer so that information about the successful verification of the new user would be associated with the ID of the old one.

The main reason the spoofing worked was that all verified devices deviate to some degree from the Secure Device Connection Protocol (SDCP), which Microsoft developed specifically to head off such attacks. The protocol takes account of many common attack scenarios — from data spoofing to replaying a data exchange between the operating system and the chip when the user is not at the computer. Hacking the implementation of the security system on a Dell (Goodix fingerprint scanner) proved possible due to the fact that the Linux driver doesn’t support SDCP, the chip stores two separate databases for Windows and Linux, and information about the choice of database is transmitted without encryption. Lenovo (Synaptics chip) uses its own encryption instead of SDCP, and the authors managed to figure out the key generation mechanism and decrypt the exchange protocol. Rather jaw-droppingly, the Microsoft keyboard (ELAN chip) doesn’t use SDCP at all, and the standard Microsoft encryption is simply absent.

Main takeaways

Hardware hacks are difficult to prevent, yet equally if not more difficult to carry out. This case isn’t about simply inserting a USB flash drive into a computer for a minute; skill and care are required to assemble and disassemble the target laptop, and throughout the period of unauthorized access the modifications to the computer are obvious. In other words, the attack cannot be carried out unnoticed, and it’s not possible to return the device to the rightful user before the hack is complete and the machine is restored to its original form. As such, primarily at risk are the computers of company employees with high privileges or access to valuable information, and also of those who often work remotely.

To mitigate the risk to these user groups:

Don’t make biometrics the only authentication factor. Complement it with a password, authenticator app, or USB token. If necessary, you can combine these authentication factors in different ways. A user-friendly policy might require a password and biometrics at the start of work (after waking up from sleep mode or initial booting), and then only biometrics during the working day;
Use external biometric scanners that have undergone an in-depth security audit;
Implement physical security measures to prevent laptops from being opened or removed from designated locations;
Combine all of the above with full-disk encryption and the latest versions of UEFI with secure boot functions activated.

Lastly, remember that, although biometric scanners aren’t perfect, hacking them is far more difficult than extracting passwords from employees. So even if biometrics aren’t not the optimal solution for your company, there’s no reason to restrict yourself to just passwords.

Kaspersky official blog – ​Read More

This season, a new attack scheme is proving very popular with cybercriminals: scamming Booking.com clients through the service’s internal messaging system. To do this, they use compromised hotel accounts on admin.booking.com. Over the past few months, various companies have released studies on incidents of this nature. Here’s a detailed breakdown of how this attack works, and tips on how hotel owners and staff can protect themselves (and their clients).

Infecting hotel staff computers with a password stealer

What we’re dealing with here is a multi-stage attack — B2B2C, if you will. It all starts with infecting hotel computers, but the immediate threat isn’t to the hotel itself — it’s to the clients.

To hijack accounts on admin.booking.com, attackers use specialized malware known as password stealers. Typically, these stealers collect any passwords found on an infected computer. But in this case it seems that Booking.com accounts are what the cybercriminals are specifically interested in.

In particular, one of the abovementioned studies describes a targeted email attack on hotel staff. This attack starts with an innocuous email in which someone poses as a recent guest and asks the hotel staff for help in finding lost documents.

In the next email, the “guest” claims to have searched everywhere for the lost passport or whatever to no avail, suggesting the hotel is the only possible place where it might be. So, they ask the hotel staff to look for it and, to help the search, provide a link supposedly containing photos of the lost passport.

As you might suspect, this archive contains not the photos of the passport, but the password stealer. After the user clicks on the dangerous file, the stealer searches the system for saved login credentials for the hotel’s account on admin.booking.com, and sends them to the attackers.

Another study on the Booking.com account theft epidemic describes an alternative method of infecting hotel staff computers. In this attack, criminals create reservations using guest accounts (in some cases, probably stolen accounts). They then contact the hotel using Booking.com’s internal messaging system and, under one pretext or another, slip in a link to a malware-infected file — with the exact same outcome as in the previous case.

Stealing hotel accounts on Booking.com and emailing clients

At the next stage, the attackers proceed to directly use the accounts stolen from the infected hotel computers. Everything is made a lot simpler by the fact that Booking.com’s service doesn’t provide two-factor authentication, so accessing an account only requires a login and password.

Upon entering the hotel’s account on admin.booking.com, the criminals study current bookings and begin sending messages to future guests using Booking.com’s internal messaging system. These messages generally revolve around an error in verifying the guest’s payment card information provided during the booking. The “hotel” thus asks the guest to re-enter their card details; otherwise, the reservation will be canceled.

Of course, the messages include links that at first glance appear to resemble genuine links to Booking.com’s booking pages. They contain the word “booking” itself, something resembling a booking number, and in some cases, additional words like “reservation”, “approve”, “confirmation”, and so on.

Of course, upon closer inspection, it’s easy to see that these links don’t lead to Booking.com at all. However, the aim here is to target hasty individuals who, unexpectedly discovering that their planned trip could be ruined, rush to rectify the situation.

The messages are written in a professional tone and appear quite plausible. It should also be noted that the text of such messages varies considerably from one described incident to another. Apparently, a number of criminals are using this scheme independently of each other.

Fake copies of Booking.com and stealing bank card data

The final stage of the attack ensues. By clicking on the link in the message, the hotel’s client lands on a fake page — a meticulous copy of Booking.com. These pages even display the correct guest name, information about the hotel where the victim intends to stay, dates, and price — all of which the scammers know because they have access to all the booking data.

The only thing that gives it away is the link in the address bar. However, the scammers distract the victim from paying attention to such minor details by rushing them: the page claims that these dates are in high demand, so “10 four-star hotels similar to this one are already unavailable”. The implication, of course, is that if this booking fails, finding alternative accommodation won’t be easy.

The victims are urged once again to confirm the booking as quickly as possible. Moreover, it’s easy to do: just re-enter the payment information. Obviously, the card details then fall into the hands of the criminals — mission accomplished.

Selling hotel logins and passwords for Booking.com

It’s worth mentioning that here, as in almost any other cybercriminal scheme, we see a tendency for narrow specialization. Apparently, some criminals collect hacked Booking.com accounts, while others exploit these accounts to deceive hotel clients. In any case, advertisements offering substantial sums for logins and passwords from admin.booking.com accounts can be found on hacker forums.

Yet another group of criminals, providing subscription-based services to search for stolen credentials in stealer malware databases, have recently added admin.booking.com to their list of searchable data.

All of this suggests that the popularity of this criminal scheme is only growing; therefore, there’ll likely be more hacks of hotel accounts on Booking.com and more affected clients in the future.

How to protect against theft of admin.booking.com accounts

Even though these attacks directly threaten hotel clients rather than the hotels themselves, the hotels still have to deal with the backlash and somehow compensate the affected parties to avoid any reputational damage. And in general, hotel computers getting infected is bad news — today, cybercriminals are hijacking Booking.com accounts; tomorrow they’ll come up with another way to monetize this infection. Therefore, it’s absolutely necessary to protect against this threat. Here’s what to keep in mind:

Storing passwords in your browser is not safe — that’s where stealer malware always looks for them.
To store passwords well, use a specialized application — a password manager — that will take care of their security.
It’s essential to install reliable protection on all your devices used for business.
And take particular care of the security of those computers that employees might use to communicate with strangers — they’re the ones more likely to become the target of an attack.

Kaspersky official blog – ​Read More

By Oded Vanunu, Dikla Barda, Roman Zaikin

Unmasking Deceptive Tactics: A recent investigation by Check Point Research exposes a troubling trend in the cryptocurrency landscape. The cryptocurrency community has been witnessing an alarming increase in sophisticated phishing attacks.

These threats are unique in their approach, targeting a wide range of blockchain networks, from Ethereum and Binance Smart Chain to Polygon, Avalanche, and almost 20 other networks by using a crypto wallet-draining technique.

Check Point’s Threat Intel blockchain system identified and alerted us on such phishing attacks:

During our investigation into some of the attacks, we came across a reoccurring address: 0x412f10aad96fd78da6736387e2c84931ac20313f and 0x0000d38a234679F88dd6343d34E26DCB50C30000 which are familiar by the names Angel Drainer address.

“Angel Drainer” refers to a notorious phishing group involved in cyberattacks, particularly in the cryptocurrency space. This group has been linked to various malicious activities, including the draining of cryptocurrency wallets through sophisticated phishing schemes.

Despite the shutdown of similar groups like Inferno Drainer, which assisted in stealing over $80 million in cryptocurrency, Angel Drainer continues its operations. These wallet drainers charge a percentage of the stolen amount from hackers in exchange for providing wallet-draining scripts and other services. The persistence of such scam-as-a-service entities poses significant challenges to the cryptocurrency market and emphasizes the importance of robust security measures to protect users and their assets.

Looking into the Angel Drainer kit in the wild, we came across a forum that gave us information about Angel Drainer service:

Before we start our deep dive into some of the techniques Angel drainer uses, let us explain what a crypto drainer is:

A crypto draining kit is crafted to facilitate cyber theft by draining funds from digital wallets. It operates primarily through phishing scams, luring victims to enter their wallet details on counterfeit websites.

Crypto drainers, also known as cryptocurrency stealers, are malicious programs or scripts designed to illegally transfer cryptocurrency from victims’ wallets without their consent.

The way most crypto drainers work is relatively straightforward:

Launch of a Malicious Campaign: Attackers create fake airdrop or phishing campaigns, often promoted on social media or via email, offering free tokens to lure users.

Deceptive Website: Users attempting to claim these tokens are directed to a fraudulent website that mimics a genuine token distribution platform.

Wallet Connection: Users are asked to connect their wallets to the website, preparing for the subsequent attack phase without immediate compromise.

Smart Contract Interaction: The user is induced to interact with a malicious smart contract under the guise of claiming the airdrop, which stealthily increases the attacker’s allowance through functions like approve or permit.

Asset Transfer and Obfuscation: Unknowingly, the user grants the attacker access to their funds, enabling token theft without further user interaction. Attackers then use methods like mixers or multiple transfers to obscure their tracks and liquidate the stolen assets.

Permit in the context of ERC-20 tokens is a feature that allows token holders to approve a spender (such as a smart contract) to transfer tokens on their behalf without conducting an on-chain transaction for each approval.

This can be done by signing a message off-chain with the token holder’s private key, which includes details like the spender’s address, the amount they are allowed to spend, and a validity period. This signed message can then be used by the spender or a contract to set the allowance on-chain. The permit function enhances user experience by reducing transaction costs and streamlines interactions in decentralized applications (dApps), especially in the DeFi sector. If the user is tricked and signs such a function, the attacker will be able to transfer his funds.

What is even more interesting in such behavior is that no trace will be logged to the blockchain because the sign is happening off-chain via communication between the wallet and the phishing DeFi website.

Deep Dive

Let’s start by examining one of the transactions used by Angel Drainer technique: 0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

If we analyze the transaction logs, we can see a few main events:

Ownership transfer event

Approval event

Transfer and Transfer events

To fully understand the sequence of events in the attack, an in-depth analysis of the smart contract at address 0x47cbbfee58e6a134d00ea3a8f1ddfff60a8d94d6 is necessary, this includes examining the specific function that was triggered, which is identified by the code 0x095838d2.

By exploring the data involved in this function call, we can uncover the particular actions executed by the smart contract and how these actions played a role in the attack, so let’s look at the data that was sent to the scammer contract:

0x095838d2000000000000000000000000c55b8ebf5ec4c76fb9182e86cb2a29eb363d919c000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000003000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000000022000000000000000000000000000000000000000000000000000000000000000e4d505accf0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000c55b8ebf5ec4c76fb9182e86cb2a29eb363d919c00000000000000b88e282822ab5ed106947c1c60af583c1741a38e858de0000000000000000000000000000000000000000000000000000000000193870b574e000000000000000000000000000000000000000000000000000000000000001ca361b0da886b37585d06e3ef06b22a1c328c949d7f6e412df12c19e2821e57935fb0f4948df32c52b17cabd6c7753129cad97e95edb1113ba181c83df0849f4200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006423b872dd0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000fbcbc1dc95eec0ecec3051fb55a8921cf5157f2800000000000000000000000000000000000000000000000083ffc624afcd500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006423b872dd0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000412f10aad96fd78da6736387e2c84931ac20313f000000000000000000000000000000000000000000000000174b4115886f87cc00000000000000000000000000000000000000000000000000000000

The function selector 0x095838d2, extracted from the initial 4 bytes of the input, clarifies that the function with this selector was executed. The parameters passed to this function were:

Param1: An Ethereum address: 0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c.

Param2: An array consisting of three identical Ethereum addresses: 0xae7ab96520de3a18e5e111b5eaab095312d7fe84 for each entry.

Param3: an array of 3 long elements.

These parameters provide insights into the nature of the transaction initiated by the contract, helping to understand the methodology of the operation within the scam.

For clarity and ease of reference, let’s label the aforementioned address with an alias:

0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c – scammer_contract_1

0xae7ab96520de3a18e5e111b5eaab095312d7fe84 – stEth_token_contract

0x9a875f6ce282e8009aa9432784f8124067032c99 – victim_address

0x412f10aad96fd78da6736387e2c84931ac20313f – angel_drainer_wallet

0x47cbbfee58e6a134d00ea3a8f1ddfff60a8d94d6 – scammer_contract_2

Function 0x095838d2(): executed by scammer_contract_2

The initial action executed involved the creation of a contract at the scammer_contract_1 address, which is referred to as Param1 in the process data.

In the screenshot below we can see:

The scammer’s strategy involves verifying the existence of a contract at the address provided in scammer_contract_1 by checking the code size at that address. If the code size is greater than zero, indicating a contract exists, the scammer proceeds to execute the multicall function on this existing contract. Subsequently, if the multicall operation is successful, a new contract is deployed.

On the other hand, if there is no existing contract at the scammer_contract_1 address (i.e., the code size is zero), the scammer’s approach changes. In this case, the first step is to deploy new contract addresses with no transaction history, enabling them to bypass wallet security alerts, followed by invoking the multicall function on this newly created contract.

In the situation we’re analyzing, the sequence of actions chosen involves first deploying a new contract, followed by the execution of the multicall function to the deployed address (scammer_contract_1) as can be seen in the screenshot below. This method highlights a particular approach to orchestrating contract interactions. Let’s proceed to examine the details of this procedure.

Function multicall(): executed by scammer_contract_1

The multicall function in question, executed on the contract at address scammer_contract_1, involves the use of two additional arrays (referred to as param2 and param3) as parameters. In this specific operation, the function is directed to carry out three distinct actions as can be seen in the screenshot below. All these actions target the same contract address, stEth_token_contract, which is associated with the stETH token and corresponds to param2 in the function call data.

In the execution of the multicall function on the contract at scammer_contract_1, the signatures for all operations were included as parameters. Analyzing the data reveals the specific function signatures that were utilized in these operations. These signatures effectively outline the set of actions to be performed by the multicall function:

0xd505accf – Permit function

0x23b872dd – TransferFrom X2

Function Call(): executed by stEth_token_contract

Let’s examine the initial transaction involving the Permit function. When we analyze the data that was submitted for this function call, we can identify the Permit signature in the first four bytes.

Breaking down the Permit function data, we note that it typically requires the following parameters:

Owner, spender, value, deadline, and V, R, S.

Understanding these parameters and their implications is key to recognizing how such functions can be exploited in scams, and why vigilance is necessary when dealing with token permissions, so let’s look at the data:

Owner: This is the address of the token owner, essentially the victim in this scenario. In our case, it’s:0x9a875f6ce282e8009aa9432784f8124067032c99.

Spender: The address that is authorized to spend the tokens, controlled by the scammer.

In our case, it’s 0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c.

Value: The specified amount of tokens the spender is permitted to use. In our case is: 83476733574422399944877753435006670731032001850387113967616000000000000000000, This extraordinarily large number typically indicates permission for an unlimited amount of tokens.

Deadline: The expiration time for the permit’s validity. In our case is: 1733137487694.

V, R, S: These are the components of the cryptographic signature, essential for verifying the authenticity of the transaction.

From this data, it’s evident that if the victim signs this permit, the scammer’s contract address would gain access to a potentially unlimited amount of the victim’s stETH tokens. This highlights the critical importance of understanding and verifying transaction details, especially in the context of token permissions and transfers.

Upon executing the Permit call with the victim’s signature, the scammer would then use the transferFrom function from scammer_contract_1 to move tokens on behalf of the victim.

Following this, another transfer is arranged from the scammer’s address to the address Angel_drainer_wallet, often referred to as the Angel drainer address, as part of a presumed agreement to distribute the stolen funds.

Upon completion of these transfers, the victim would be deprived of all their stETH tokens. Subsequently, the scammer would change the ownership of the contract address they used for the attack, scammer_contract_1, transferring it from one contract address to another scammer controlled address. This final step would effectively complete the scam operation, leaving the victim without their tokens and the scammer in control of the new contract.

Looking at the “Angel Drainer” wallet address, it seems that he earns significant amounts of money not just through direct activities but also from others using its drain kit.

Safeguarding Your Assets

The risks involved in these scams are manifold. First and foremost is the risk of unsolicited emails and messages, which are a common starting point for these phishing attacks. Users must be extremely cautious with such communications, especially when they lead to external links. Another significant risk is the use of URLs that closely mimic legitimate ones, designed to deceive even the most vigilant eye. The most critical risk, however, is embedded in the approval of transactions that seem innocuous but are, in fact, malicious.

The key to safeguarding against these phishing attacks lies in a combination of vigilance and the use of technological safeguards. Users are advised to:

Be skeptical of airdrop claims, especially those requiring wallet interaction.

Understand the implications of approving transactions or signing messages in their wallets.

Verify the legitimacy of smart contracts before interacting with them.

Limit the use of high allowances or regularly review and revoke them using blockchain explorers or wallet interfaces.

Employ hardware wallets for enhanced security, especially for substantial holdings.

Conclusion

The threat posed by these phishing attacks cannot be overstated. In the dynamic and ever-evolving world of cryptocurrency, staying informed and cautious is not just advisable; it’s essential. The community needs to collectively work towards building a more secure and aware environment, where each member is equipped with the knowledge and tools to protect their digital assets. Remember, in the realm of cybersecurity, it’s always better to err on the side of caution. Let’s spread the word and help keep our community safe.

The Threat Intel Blockchain system, developed by Check Point, continues to accumulate valuable information on emerging threats, and this intelligence will be shared in the future. In this collaborative effort, we aim to empower investors with the knowledge needed to navigate the crypto space securely and protect themselves from potential pitfalls. For more information contact us at: blockchain@checkpoint.com

The post The Rising Threat of Phishing Attacks with Crypto Drainers appeared first on Check Point Research.

Check Point Research – ​Read More