{
	"id": "e3611846-2e78-4cb1-a61d-52383aba78e1",
	"created_at": "2026-04-06T00:12:26.638376Z",
	"updated_at": "2026-04-10T03:35:51.150902Z",
	"deleted_at": null,
	"sha1_hash": "11fcd89425219e6f04a62fc062c9284bbb39ac82",
	"title": "Inside the BlueNoroff Web3 macOS Intrusion Analysis | Huntress",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4143526,
	"plain_text": "Inside the BlueNoroff Web3 macOS Intrusion Analysis | Huntress\r\nArchived: 2026-04-05 20:19:49 UTC\r\nSummary\r\nOn June 11, 2025, Huntress received contact from a partner saying that an end user had downloaded, potentially, a\r\nmalicious Zoom extension. The depth of the intrusion became immediately apparent upon installing the Huntress EDR\r\nagent, and after some analysis, it was discovered that the lure used to gain access was received by the victim several weeks\r\nprior.\r\nThis post aims to provide a detailed analysis from beginning to end of the intrusion, including a full breakdown of several\r\nnew pieces of malware used by the threat actors.\r\nWe attribute with high confidence that this intrusion was conducted by the North Korean (DPRK) APT subgroup tracked as\r\nTA444 aka BlueNoroff, Sapphire Sleet, COPERNICIUM, STARDUST CHOLLIMA, or CageyChameleon—a state-sponsored threat actor known for targeting cryptocurrencies stemming back to at least 2017.\r\nFigure 1: Visualization of attack chain\r\nInitial access\r\nThe setup:\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 1 of 36\n\nAn employee at a cryptocurrency foundation received a message from an external contact on their Telegram. The message\r\nrequested time to speak to the employee, and the attacker sent a Calendly link to set up meeting time. The Calendly link\r\nwas for a Google Meet event, but when clicked, the URL redirects the end user to a fake Zoom domain controlled by the\r\nthreat actor.\r\nFigure 2: .ics meeting invitation file sent to the employee under the guise of a Google Meeting\r\nSeveral weeks later, when the employee joined what ended up being a group Zoom meeting, it contained several deepfakes\r\nof known senior leadership within their company, along with external contacts. During the meeting, the employee was\r\nunable to use their microphone, and the deepfakes told them that there was a Zoom extension they needed to download. \r\nThe link to this “Zoom extension” sent to them via Telegram was hxxps[://]support[.]us05web-zoom[.]biz/troubleshoot-issue-727318. The file downloaded in turn was an AppleScript (Apple’s built-in scripting language) named\r\nzoom_sdk_support.scpt.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 2 of 36\n\nFigure 3: Initial payload sent to the victim - zoom_sdk_support.scpt\r\nThis AppleScript first opens a legitimate webpage for Zoom SDKs, but after over 10,500 blank lines, it downloads a\r\npayload from a malicious website, https[://]support[.]us05web-zoom[.]biz, and after downloading completes, runs a script.\r\nWhile we weren’t able to recover this second stage from the intrusion, we were able to find a version on VirusTotal that\r\nprovides good insight as to what happens next.\r\nThe script begins by disabling bash history logging and then checks if Rosetta 2, which allows Apple Silicon Macs to run\r\nx86_64 binaries, is installed. If it isn’t, it silently installs it to ensure x86_64 payloads can run. It then creates a file called\r\n.pwd, which is hidden from the user’s view due to the period prepending it and downloads the payload from the malicious,\r\nfake Zoom page to /tmp/icloud_helper. \r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 3 of 36\n\nFigure 4: Disable logging, install Rosetta 2, and download binary\r\nNext, it performs another curl request using the cur1-request user agent. This has been observed in previous BlueNoroff\r\nintrusions like the one covered by Kasperksy in 2022. Unfortunately, this payload was also not live at the time of analysis. \r\nFigure 5: Printing the “progress” extracting the download payload\r\nThen attempt to get the user’s password and verify it using sudo. They will continue doing this until a valid password is\r\nsupplied.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 4 of 36\n\nFigure 6: Attempting to verify the user's password\r\nLastly, it removes the shell history, so users are unaware of what ran. During our investigation, we noted that these history\r\nfiles had been modified at the time of the attack.\r\nFigure 7: bash script removing shell history\r\nTechnical analysis\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 5 of 36\n\nBy the end of our investigation, we recovered 8 different malicious binaries from the victim host. We’ll cover the\r\nfunctionality of some of these binaries in this section. To quickly summarize what each one is:\r\nTelegram 2: the persistent binary, written in Nim, responsible for starting the primary backdoor.\r\nRoot Troy V4 (remoted): fully featured backdoor, written in Go, and used to download the other payloads as well\r\nas run them. \r\nInjectWithDyld (a): a binary loader written in C++ that is downloaded by Root Troy V4. It will decrypt two\r\nadditional payloads.\r\nBase App: A benign Swift application that is injected into.\r\nPayload: A different implant written in Nim, with command execution capability.\r\nXScreen (keyboardd): a keylogger written in Objective-C that has capability to monitor keystrokes, the clipboard,\r\nand the screen.\r\nCryptoBot (airmond): an infostealer written in Go that is designed to collect cryptocurrency related files from the\r\nhost.\r\nNetChk: an almost empty binary that will generate random numbers forever.\r\nMost of the implants, with the exception of the ones written in Nim, contained build artifacts showing the usernames of\r\nthose who compiled the binaries. There were 4 personas responsible for different tooling:\r\nFigure 8: Usernames of attacker machines responsible for compiling certain tooling\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 6 of 36\n\nPersistent implant: Telegram 2\r\nThe core implant responsible for running all the other components is called Telegram 2 and is written in Nim. It persists out\r\nof /Library/LaunchDaemons/com.telegram2.update.agent.plist, running a binary at /Library/Application\r\nSupport/Frameworks/Telegram 2. The binary is adhoc signed with the identifier root_startup_loader_arm64.\r\nTelegram 2 was used as the persistence mechanism and starting hourly, with the following plist: \r\nFigure 9: com.telegram2.update.agent LaunchDaemon \r\nConfiguration\r\nUpon execution, this binary will create a config file in /private/var/tmp/cfg. Unfortunately, we weren’t able to recover this\r\nfile from the victim machine. \r\nFunctionality\r\nThis binary is very small and only has a few pieces of functionality:\r\npoEchoCmd: run an echo command (testing)\r\npoEvalCommand: run a command using /bin/bash\r\npoInteractive: spawn an interactive shell\r\npoDaemon: initialize persistence\r\nBackdoor: Root Troy V4 (remoted)\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 7 of 36\n\nThis binary which was found running from /Library/WebServer/bin/remoted is a fully featured backdoor written in Go.\r\nBuild artifacts show it’s actually called “Root Troy V4” or “RTV”.\r\nFigure 10: Build artifacts show user “dominic” and project structure\r\nThe primary use we saw for this binary was to execute an AppleScript payload to download and execute another implant\r\n(covered in the next section). This command was run 6 times from when the customer was onboarded to when the host was\r\nisolated.\r\nFigure 11: remoted curling down additional implants\r\nConfiguration\r\nThe binary stores associated information such as its configuration, payload versions, and startup commands in a directory\r\nlocated at /Library/Google/Cache/. The configuration file (.cfg) is encrypted with an RC4 key\r\n(3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A) found in the binary. It contains\r\nthe C2 information along with user IDs (redacted here).\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 8 of 36\n\nFigure 12: Contents of the configuration file\r\nThere is also a version file (.version) encrypted with another RC4 key\r\n(C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF). It contains the version\r\ninformation for two of the payloads used later: {\"cbot\":\"1.0.1\",\"rt\":\"4.0.1\"}. \r\nThe file .startup contains commands that should be run whenever a user logs in. It will start running the keylogging binary\r\nand one of the binaries contained in the .version file:\r\nFigure 13: Contents of the .startup script file\r\nMain execution\r\nWhen main runs, it first creates the directory to store the configuration files:\r\nFigure 14: Creating the config directory\r\nThen it attempts to load the C2 information from inside the binary, which we covered in the last section. For whatever\r\nreason if that fails, they will kill the current process, delete the artifacts and exit.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 9 of 36\n\nFigure 15: Self deletion if config extraction fails\r\nAfter checking that configuration is all good, and there aren’t other instances running using the PID file, it will run two new\r\nthreads: the execStartup function, which runs the script detailed earlier, and logoutMonitor which watches for the user\r\nlogging out. If that happens it will trigger execStartup again.\r\nFigure 16:  New threads to run script and monitor logout\r\nFinally, it enters an infinite loop that collects the /Volumes from the system, as well as the running process list. These are\r\nsent to the C2 server periodically using the sendRequest function.\r\nCapability: Remote code execution\r\nThere are several different ways an operator can execute commands on the host using this malware:\r\nexecScript: run a remote AppleScript payload using osascript -e.\r\nexecShell: run a shell command using /bin/zsh -sc\r\nexecShellDetached: run a shell command using /bin/zsh -sc in the background\r\nCapability: Execution during sleep\r\nTo avoid any instances where a user might observe code being executed, commands are wrapped by a checkSleep function\r\nwhich queries the state of the display. If the display is asleep, commands are executed, otherwise they are entered into a\r\nqueue for later execution. To accomplish this they use system_profiler SPDisplaysDataType and look for the Online field.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 10 of 36\n\nFigure 17: Example output of querying system_profiler SPDisplaysDataType\r\nC2 Communications\r\nRequests to the C2 are sent to http://$DOMAIN/update and contain the host information collected using the function\r\nhost.PlatformInformationWithContext from the library github.com/shirou/gopsutil/. It also supplies the boot time, and the\r\nversions of the other implants currently running.\r\nLoader: InjectWithDyld (a)\r\nAs mentioned before, the binary called a was downloaded by remoted using the AppleScript payload. The password found\r\nin that download cradle is required for this binary to work correctly as it’s used to derive the AES keys for payload\r\ndecryption. To quickly review what the threat actor did with this binary:\r\nFigure 18: Script run by remoted to install and run a\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 11 of 36\n\nThere are two main things this binary does: in the first, it takes another binary and a password as arguments and will\r\ndecrypt embedded payloads. In the second, it simply takes the argument --d and will overwrite all files in the current\r\ndirectory with zeros as an antiforensic measure. The actors first ran the payload with the parameters ./cloudkit and a\r\npassword of gift123$%^.\r\nKey derivation function\r\nTo decrypt both the payload and the base app, the supplied password is used with Password-Based Key Derivation Function\r\n(PBKDF) to derive AES keys.\r\nFigure 19: Decompilation of password supplied to key deviation function\r\nThe salt is prepended to the actual payload, in the case of the baseApp it’s the base64 decoded GJM0bP36hbomz9Gw. \r\nFigure 20: Salt prepended to the payload base64\r\nPayload decryption\r\nAfter the key has been derived, the sample then decrypts the two payloads using a modified version of AES-CFB. They\r\npass the base64 decoded content, skipping the salt bytes, and the key to the AesEncrypt function.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 12 of 36\n\nFigure 21: Decompilation of base64 decoding the payload and skipping the first 16 bytes (salt)\r\nThey iterate through the decoded base64 and call AesTrans on each block, which encrypts the buffer using AES, this output\r\nis then XORed against the original resulting in the decrypted content.\r\nFigure 22: AES-CFB implementation\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 13 of 36\n\nFigure 23: Decompilation of decryption routine\r\nThis occurs for both base64 blobs which are later used in the process injection portion.\r\nProcess injection\r\nBy far the most interesting part about this malware is how it deploys the malicious payload. Anyone who looks at Windows\r\nis extremely familiar with the technique of process injection, in which a process will write code into another process’\r\nmemory. But, historically process injection hasn’t been common on macOS because there’s a large number of prerequisites\r\nneeded to bypass Apple’s memory protections.\r\nThis sample takes advantage of some edge cases in Apple’s security model to allow for injection! Binaries that want to do\r\nthis need a debugging tool entitlement(s), which allows them to attach to other processes and more importantly get task\r\nports. This binary, and several of the others used in this intrusion have this:\r\ncom.apple.security.cs.debugger\r\ncom.apple.security.get-task-allow\r\nAfter decrypting the payload the malware will check the magic bytes of the resulting macho file. If they are 0xbebafeca it’s\r\na FAT executable (meaning both an ARM and x86_64 binary glued together), so it has to iterate over the FAT header entries\r\nuntil it finds the x86_64 macho header. Otherwise, if the magic bytes are 0xfeedfacf it is just an x86_64 macho and that\r\nisn’t necessary, so it can just call the injection routine. The same process occurs for the ARM executable but it looks for a\r\ncputype of CPU_TYPE_ARM64.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 14 of 36\n\nFigure 24: Setup to calling process injection code\r\nThen the process of injection begins, by calling InjectAMD64, which is illustrated in the following figure:\r\nFigure 25: Decompilation of InjectAMD64 function with posix_spawnattrs\r\nTo kick off the injection process, a new process is spawned with the attributes setup before. Then task_for_pid is called on\r\nthe process, which will return the Mach port of the process. Having access to this port allows the malware to utilize the\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 15 of 36\n\nmach_vm APIs allowing for arbitrary memory manipulation and task management. \r\nFigure 26: Decompilation of getting a Mach port on the sacrificial process\r\nFrom there, they get a list of threads associated with the process using task_threads. If that is successful, they begin to parse\r\nthe mach-o header of the decrypted payload. This is a very similar process to how they decide whether or not to call the\r\ninject routine for a FAT binary or not. They do this to find the total number of segments in the payload binary.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 16 of 36\n\nFigure 27: Parsing payload mach-o in preparation for copying\r\nAt this point, the malware begins to copy the segments from the payload binary into the sacrificial process and modifies the\r\nmemory to allow for execution. The following decompiled code shows how the page permissions were modified to read\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 17 of 36\n\nand write, as seen in the _mac_vm_protect function, where the new_protection variable is set to 3 (VM_PROT_READ |\r\nVM_PROT_WRITE).\r\nFigure 28: Decompilation of the memory protection modifications per segment\r\nAfter making the aforementioned memory modifications, the sleeping process is then restored with the injected payload, as\r\nseen in the following figure: \r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 18 of 36\n\nFigure 29: Decompilation of restoring the sleeping process to execute the injected payload\r\nPayload cleanup\r\nAfter the payloads were deployed, the actor then ran the binary using the --d flag which calls the ZeroWrite function. This\r\niterates over all files in the current directory, and will write null bytes over all contained functions.\r\nDecrypted Payloads: Nim Implant (Trojan 1) \u0026 Base App \r\nAs was mentioned, there are two binaries decrypted by the previous step. \r\nNim Implant (Trojan 1)\r\nThe Nim implant is primarily used to interactively send commands to and from the infected host. The primary file is called\r\ntrojan1.nim and allows the operator to issue commands and receive responses asynchronously. To communicate with the C2\r\nit uses websockets wss[:]//firstfromsep[.]online/client. \r\nAnalysis is still in progress on this binary and the post will be updated when complete.\r\nBase app\r\nThe base application is a relatively bare-bones binary written in Swift by the author dominic. \r\nFigure 30: Build artifacts from base executable\r\nThe main method just runs a simple task on a loop (every 3.37 seconds).\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 19 of 36\n\nFigure 31: Main method from the base app\r\nThe task simply prints the string Current: YYYY-MM-DD HH:MM:SS to /dev/null. This is probably just to keep the binary\r\nalive so it can be injected at some point in the future if needed.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 20 of 36\n\nFigure 32: Closure called by the main method\r\nKeylogger: XScreen (keyboardd)\r\nThis binary is used for keylogging, screen recording, and clipboard retrieval. It is written in Objective-C and was compiled\r\nby a user named pooh.\r\nFigure 33: Build artifacts from keyboardd binary\r\nTo start execution, it will first check if the file /Users/Shared/._cfg exists, which contains the C2 URL. It defaults to using\r\nthe server https[:]//metamask[.]awaitingfor[.]site/update but in this case it was the same as the URL found in the recovered\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 21 of 36\n\n._cfg file.\r\nFigure 34: Decompilation of C2 resolution\r\nIt accepts 3 potential command line arguments:\r\n-u: use a custom C2 domain\r\n-c: how long to sleep between screen captures\r\n-p: if clipboard should be monitored\r\nIn the case of this intrusion it was called repeatedly by the remoted binary with the -p argument. \r\nThe overall way this binary works is by starting 3 asynchronous loops, one for each type of collection. The first loop will\r\nsend the content of the keylog buffer to the C2 server:\r\nFigure 35: Decompilation of async loop 1\r\nThe second calls the MonitorClipboared (sic) function in a loop:\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 22 of 36\n\nFigure 36: MonitorClipboared callback\r\nThe last is responsible for the screen collection functionality discussed in the next section.\r\nKeylogging functionality \r\nThe actual keylogging functionality is implemented using the Core Graphics library with the EventTapCreate API. This API\r\ntakes a callback function that will execute every time a keypress event is registered. \r\nFigure 37: Keylogging function loop\r\nThe first thing the callback function will do is keep track of what application was being interacted with for each keypress.\r\nThey do this by querying frontmostApplication and grab that app name’s bundle identifier. If it is different from the last\r\ncall, they will log the application name and time to the keylog buffer:\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 23 of 36\n\nFigure 38: Callback function checking which active window is being used\r\nAfter that happens, they will check if the keycode is a printable character. If it’s a special one (control, command, etc.) they\r\nwill convert it to a text representation and then append it to the keylog buffer:\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 24 of 36\n\nFigure 39: Converting non-printable characters to a text representation\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 25 of 36\n\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 26 of 36\n\nFigure 40: Conversion outputs\r\nScreencapture functionality\r\nTo capture the screens, the malware enters an infinite loop that checks the number of active displays using\r\nCGGetActiveDsiplayList. If there is at least one active display it will start capturing data, and if there are more than one it\r\nwill iterate over all available screens to capture each one.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 27 of 36\n\nFigure 41: Decompilation of the screen recording driver function\r\nThe function CaptureAndSend is responsible for actually gathering the data. It takes an image of the display using the\r\nCGDisplayCreateImage API, and then saves that content to a file located at /private/tmp/google_cache.db. If that is\r\nsuccessful, it will convert the image to base64 and append the letter “I” so that the C2 can delineate what data is an image.\r\nFinally, it uses the same SendData function to send everything off to the C2 server.\r\nDuring our investigation, we did not find any data stored at the file save location.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 28 of 36\n\nFigure 42: Decompilation of CaptureAndSend function\r\nClipboard functionality\r\nTo monitor the clipboard, they simply grab the system pasteboard, and then extract the text content from that object. The\r\ninfinite loop will monitor if there has been a change to the clipboard content and if so it will write the content to the shared\r\nkeylog buffer.\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 29 of 36\n\nFigure 43: Decompilation of clipboard monitoring code\r\nSend data\r\nTo send the data to the C2 server, they create a string that contains a UUID, the uid of the victim, the data, the username,\r\nand a token embedded in the binary:\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 30 of 36\n\nFigure 44: Sending data to the C2 server\r\nInfostealer: CryptoBot (airmond)\r\nThe airmond binary is a full-featured infostealer with a focus on cryptocurrency theft. It is written in Go and has a large\r\nnumber of build artifacts showing it’s a project called CryptoBot compiled by a user chris. \r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 31 of 36\n\nFigure 45: Compilation artifacts from airmond binary\r\nConfiguration\r\nMuch like the other malware in this incident, CryptoBot makes use of several files in its current directory \r\n/Library/AirPlay/.pid: A PID file for preventing multiple instances.\r\n/Library/AirPlay/.cache: A cache to store collected crypto data.\r\n/Library/AirPlay/.CFUserTextEncoding: User and a key (user|key)\r\n/Library/Google/Cache/.cfg: Shared config with the “Root Troy V4” binary.\r\n/Library/Google/Cache/.version: Shared version info with “Root Troy V4” binary. \r\nThe config files in the AirPlay directory are encrypted using AES-CFB with an IV of 0. The key is static and is embedded\r\nin the binary f6102a492570dee84bbc9ebd8bd7bfab4e442eae3b416b1a. Several initialization functions are used to create\r\nthe previously mentioned files:\r\nmain.initializeCryptoCache\r\nmain.initializeUserInfo\r\nmain.initializeVersion\r\nmain.writePid\r\nAnd there are another set of functions to load those configuration files while running:\r\nmain.loadUserInfo\r\nmain.loadVersions\r\nmain.writeCryptoCache\r\nmain.readCryptoCache\r\nCrypto Stealer\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 32 of 36\n\nThe main purpose of this binary is to index cryptocurrency-related information from the host. As is typical with stealers to\r\ndo this, they iterate over installed browser extensions looking for wallet plugins. If those are found, it then calls a number\r\nof helper functions designed to extract the sensitive information from those extensions. They are all contained in the crypto-bot module:\r\ncrypto-bot/wallet.ExtractAddressInfosFromBinance\r\ncrypto-bot/wallet.ExtractAddressInfosFromBitget\r\ncrypto-bot/wallet.ExtractAddressInfosFromCoin\r\ncrypto-bot/wallet.ExtractAddressInfosFromKeplr\r\ncrypto-bot/wallet.ExtractAddressInfosFromLeather\r\ncrypto-bot/wallet.ExtractAddressInfosFromMetamask\r\ncrypto-bot/wallet.ExtractAddressInfosFromNabox\r\ncrypto-bot/wallet.ExtractAddressInfosFromOKX\r\ncrypto-bot/wallet.ExtractAddressInfosFromPhantom\r\ncrypto-bot/wallet.ExtractAddressInfosFromPhantom.Println.func1\r\ncrypto-bot/wallet.ExtractAddressInfosFromRabby\r\ncrypto-bot/wallet.ExtractAddressInfosFromRainbow\r\ncrypto-bot/wallet.ExtractAddressInfosFromRonin\r\ncrypto-bot/wallet.ExtractAddressInfosFromSafepal\r\ncrypto-bot/wallet.ExtractAddressInfosFromSender\r\ncrypto-bot/wallet.ExtractAddressInfosFromStation\r\ncrypto-bot/wallet.ExtractAddressInfosFromSubwallet\r\ncrypto-bot/wallet.ExtractAddressInfosFromSui\r\ncrypto-bot/wallet.ExtractAddressInfosFromTon\r\ncrypto-bot/wallet.ExtractAddressInfosFromTron\r\ncrypto-bot/wallet.ExtractAddressInfosFromTrust\r\ncrypto-bot/wallet.ExtractAddressInfosFromUnisat\r\ncrypto-bot/wallet.ExtractAddressInfosFromXverse\r\nC2 interaction\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 33 of 36\n\nThe binary interacts with a C2 at productnews[.]online using HTTP. Requests are encrypted using the same key and\r\nalgorithm used to encrypt the configuration files. There is also an option to send unencrypted packets if necessary:\r\nmain.postEncryptedData\r\nmain.postToServer\r\nIdentifying and mitigating Meeting application social engineering\r\nRemote workers, especially in high-risk areas of work are often the ideal targets for groups like TA444. It is important to\r\ntrain employees to identify common attacks that start off with social engineering related to remote meeting software:\r\nBe wary of Calendar invites that are marked with urgency from individuals you haven’t communicated with in some\r\ntime, or groups of individuals that are not normally in meetings together.\r\nUsers should be immediately wary of sudden, unnatural changes such as switching meeting platforms at the last\r\nminute, a request to install an “Extension” or “Plugin”, unpopular TLD names such as .biz, .xyz, .site, .online, or\r\n.click, and requests to enable remote access or similar controls.\r\nAdvise employees in the event any of these indicators, or even uncertainty, to disconnect the Meeting software\r\nimmediately and report this to your security teams, HR, and other teams.\r\nConclusion\r\nHistorically, macOS has been viewed as a smaller target compared to its Windows counterpart. Spoken alongside the “Macs\r\ndon’t get viruses” adage that has permeated the space over the last two decades, they are often seen as “not requiring\r\nprotection.” Due to these sentiments, it understandably dovetails into more targeted attacks. Over the last few years, we\r\nhave seen macOS become a larger target for threat actors, especially with regard to highly sophisticated, state-sponsored\r\nattackers.\r\nIn this instance, we saw BlueNoroff utilizing Mac-specific techniques in a very targeted attack. They leveraged\r\nAppleScript, which is unique to macOS, multiple implants, keyloggers, and screencaptures. Additionally, they would\r\ncapture contents of the clipboard, clean up their session history, and also look for a very extensive array of cryptowallets,\r\nshowcasing their focus on macOS.\r\nAs these attacks and the frequency in which they occur continue to rise, it will be evermore important to protect your Macs.\r\nAs we saw here, the attackers didn’t just use common, cross-platform attack techniques, but instead leveraged Mac-specific\r\nbinaries, APIs, and functionality. \r\nIOCs\r\nFiles\r\nName SHA256 Notes\r\na 4cd5df82e1d4f93361e71624730fbd1dd2f8ccaec7fc7cbdfa87497fb5cb438c C++ Dropper\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 34 of 36\n\nremoted ad01beb19f5b8c7155ee5415781761d4c7d85a31bb90b618c3f5d9f737f2d320 Go Backdoor\r\nairmond ad21af758af28b7675c55e64bf5a9b3318f286e4963ff72470a311c2e18f42ff Go Infostealer\r\nkeyboardd 432c720a9ada40785d77cd7e5798de8d43793f6da31c5e7b3b22ee0a451bb249\r\nObj-C\r\nkeylogger /\r\nscreenrecorder\r\nzoom_sdk_support.scpt 1ddef717bf82e61bf79b24570ab68bf899f420a62ebd4715c2ae0c036da5ce05\r\nInitial access\r\nAppleScript\r\npayload\r\nTelegram 2 14e9bb6df4906691fc7754cf7906c3470a54475c663bd2514446afad41fa1527\r\nPersistent\r\nNim implant\r\ncloudkit 2e30c9e3f0324011eb983eef31d82a1ca2d47bbd13a6d32d9e11cb89392af23d\r\nSacrificial\r\nbinary used\r\nfor process\r\ninjection\r\nnetchk 469fd8a280e89a6edd0d704d0be4c7e0e0d8d753e314e9ce205d7006b573865f\r\nC Injection\r\ncandidate\r\npayload 080a52b99d997e1ac60bd096a626b4d7c9253f0c7b7c4fc8523c9d47a71122af Nim Implant\r\nbaseApp 2e30c9e3f0324011eb983eef31d82a1ca2d47bbd13a6d32d9e11cb89392af23d\r\nSwift\r\nInjection\r\nCandidate\r\nInfrastructure\r\nIP Notes\r\nhxxps[://]safeupload[.]online\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 35 of 36\n\nhxxps[://]metamask[.]awaitingfor[.]site/update C2 server for keylogger\r\nhxxps[://]support[.]us05web-zoom[.]biz/842799/checkInitial url sent to victim via Telegram, resulting in download of\r\nzoom_sdk_support.scpt\r\nproductnews[.]online C2 for CryptoBot\r\nfirstfromsep[.]online C2 for a’s Nim Payload\r\nsafefor[.]xyz C2 for RTV4\r\nreadysafe[.]xyz C2 for RTV4\r\nSource: https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nhttps://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis\r\nPage 36 of 36\n\nAfter decrypting a FAT executable the payload the malware (meaning both an ARM will check the and x86_64 magic bytes binary glued of the resulting together), so macho file. it has to iterate over If they are 0xbebafeca the FAT header it’s entries\nuntil it finds the x86_64 macho header. Otherwise, if the magic bytes are 0xfeedfacf it is just an x86_64 macho and that\nisn’t necessary, so it can just call the injection routine. The same process occurs for the ARM executable but it looks for a\ncputype of CPU_TYPE_ARM64.       \n   Page 14 of 36",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis"
	],
	"report_names": [
		"inside-bluenoroff-web3-intrusion-analysis"
	],
	"threat_actors": [
		{
			"id": "9de1979b-40fc-44dc-855d-193edda4f3b8",
			"created_at": "2025-08-07T02:03:24.92723Z",
			"updated_at": "2026-04-10T02:00:03.755516Z",
			"deleted_at": null,
			"main_name": "GOLD LOCUST",
			"aliases": [
				"Anunak",
				"Carbanak",
				"Carbon Spider ",
				"FIN7 ",
				"Silicon "
			],
			"source_name": "Secureworks:GOLD LOCUST",
			"tools": [
				"Carbanak"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "cfdd35af-bd12-4c03-8737-08fca638346d",
			"created_at": "2022-10-25T16:07:24.165595Z",
			"updated_at": "2026-04-10T02:00:04.887031Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Cosmic Wolf",
				"Marbled Dust",
				"Silicon",
				"Teal Kurma",
				"UNC1326"
			],
			"source_name": "ETDA:Sea Turtle",
			"tools": [
				"Drupalgeddon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "810fada6-3a62-477e-ac11-2702f9a1ef80",
			"created_at": "2023-01-06T13:46:38.874104Z",
			"updated_at": "2026-04-10T02:00:03.129286Z",
			"deleted_at": null,
			"main_name": "STARDUST CHOLLIMA",
			"aliases": [
				"Sapphire Sleet"
			],
			"source_name": "MISPGALAXY:STARDUST CHOLLIMA",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d14271be-be2e-4be7-9578-5b6196e35481",
			"created_at": "2023-11-21T02:00:07.355328Z",
			"updated_at": "2026-04-10T02:00:03.46613Z",
			"deleted_at": null,
			"main_name": "TA444",
			"aliases": [],
			"source_name": "MISPGALAXY:TA444",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "33ae2a40-02cd-4dba-8461-d0a50e75578b",
			"created_at": "2023-01-06T13:46:38.947314Z",
			"updated_at": "2026-04-10T02:00:03.155091Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"UNC1326",
				"COSMIC WOLF",
				"Marbled Dust",
				"SILICON",
				"Teal Kurma"
			],
			"source_name": "MISPGALAXY:Sea Turtle",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "732597b1-40a8-474c-88cc-eb8a421c29f1",
			"created_at": "2025-08-07T02:03:25.087732Z",
			"updated_at": "2026-04-10T02:00:03.776007Z",
			"deleted_at": null,
			"main_name": "NICKEL GLADSTONE",
			"aliases": [
				"APT38 ",
				"ATK 117 ",
				"Alluring Pisces ",
				"Black Alicanto ",
				"Bluenoroff ",
				"CTG-6459 ",
				"Citrine Sleet ",
				"HIDDEN COBRA ",
				"Lazarus Group",
				"Sapphire Sleet ",
				"Selective Pisces ",
				"Stardust Chollima ",
				"T-APT-15 ",
				"TA444 ",
				"TAG-71 "
			],
			"source_name": "Secureworks:NICKEL GLADSTONE",
			"tools": [
				"AlphaNC",
				"Bankshot",
				"CCGC_Proxy",
				"Ratankba",
				"RustBucket",
				"SUGARLOADER",
				"SwiftLoader",
				"Wcry"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "62b1b01f-168d-42db-afa1-29d794abc25f",
			"created_at": "2025-04-23T02:00:55.22426Z",
			"updated_at": "2026-04-10T02:00:05.358041Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Sea Turtle",
				"Teal Kurma",
				"Marbled Dust",
				"Cosmic Wolf",
				"SILICON"
			],
			"source_name": "MITRE:Sea Turtle",
			"tools": [
				"SnappyTCP"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "a2b92056-9378-4749-926b-7e10c4500dac",
			"created_at": "2023-01-06T13:46:38.430595Z",
			"updated_at": "2026-04-10T02:00:02.971571Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Operation DarkSeoul",
				"Bureau 121",
				"Group 77",
				"APT38",
				"NICKEL GLADSTONE",
				"G0082",
				"COPERNICIUM",
				"Moonstone Sleet",
				"Operation GhostSecret",
				"APT 38",
				"Appleworm",
				"Unit 121",
				"ATK3",
				"G0032",
				"ATK117",
				"NewRomanic Cyber Army Team",
				"Nickel Academy",
				"Sapphire Sleet",
				"Lazarus group",
				"Hastati Group",
				"Subgroup: Bluenoroff",
				"Operation Troy",
				"Black Artemis",
				"Dark Seoul",
				"Andariel",
				"Labyrinth Chollima",
				"Operation AppleJeus",
				"COVELLITE",
				"Citrine Sleet",
				"DEV-0139",
				"DEV-1222",
				"Hidden Cobra",
				"Bluenoroff",
				"Stardust Chollima",
				"Whois Hacking Team",
				"Diamond Sleet",
				"TA404",
				"BeagleBoyz",
				"APT-C-26"
			],
			"source_name": "MISPGALAXY:Lazarus Group",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f426f0a0-faef-4c0e-bcf8-88974116c9d0",
			"created_at": "2022-10-25T15:50:23.240383Z",
			"updated_at": "2026-04-10T02:00:05.299433Z",
			"deleted_at": null,
			"main_name": "APT38",
			"aliases": [
				"APT38",
				"NICKEL GLADSTONE",
				"BeagleBoyz",
				"Bluenoroff",
				"Stardust Chollima",
				"Sapphire Sleet",
				"COPERNICIUM"
			],
			"source_name": "MITRE:APT38",
			"tools": [
				"ECCENTRICBANDWAGON",
				"HOPLIGHT",
				"Mimikatz",
				"KillDisk",
				"DarkComet"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "1bdb91cf-f1a6-4bed-8cfa-c7ea1b635ebd",
			"created_at": "2022-10-25T16:07:23.766784Z",
			"updated_at": "2026-04-10T02:00:04.7432Z",
			"deleted_at": null,
			"main_name": "Bluenoroff",
			"aliases": [
				"APT 38",
				"ATK 117",
				"Alluring Pisces",
				"Black Alicanto",
				"Bluenoroff",
				"CTG-6459",
				"Copernicium",
				"G0082",
				"Nickel Gladstone",
				"Sapphire Sleet",
				"Selective Pisces",
				"Stardust Chollima",
				"T-APT-15",
				"TA444",
				"TAG-71",
				"TEMP.Hermit"
			],
			"source_name": "ETDA:Bluenoroff",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434346,
	"ts_updated_at": 1775792151,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/11fcd89425219e6f04a62fc062c9284bbb39ac82.pdf",
		"text": "https://archive.orkl.eu/11fcd89425219e6f04a62fc062c9284bbb39ac82.txt",
		"img": "https://archive.orkl.eu/11fcd89425219e6f04a62fc062c9284bbb39ac82.jpg"
	}
}