{ "id": "b525c6b0-df28-4e9f-8db7-0ea6ca7d6e4f", "created_at": "2026-04-06T00:17:37.95664Z", "updated_at": "2026-04-10T03:37:50.785767Z", "deleted_at": null, "sha1_hash": "093ef4e54c487b33a0b83aef95f8749ae4a511b3", "title": "The Nearest Neighbor Attack: How A Russian APT Weaponized Nearby Wi-Fi Networks for Covert Access", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 681276, "plain_text": "The Nearest Neighbor Attack: How A Russian APT Weaponized\r\nNearby Wi-Fi Networks for Covert Access\r\nBy mindgrub\r\nPublished: 2024-11-22 · Archived: 2026-04-02 12:41:05 UTC\r\nIn early February 2022, notably just ahead of the Russian invasion of Ukraine, Volexity made a discovery that led\r\nto one of the most fascinating and complex incident investigations Volexity had ever worked. The investigation\r\nbegan when an alert from a custom detection signature Volexity had deployed at a customer site (“Organization\r\nA”) indicated a threat actor had compromised a server on the customer’s network. While Volexity quickly\r\ninvestigated the threat activity, more questions were raised than answers due to a very motivated and skilled\r\nadvanced persistent threat (APT) actor, who was using a novel attack vector Volexity had not previously\r\nencountered. At the end of the investigation, Volexity would tie the breach to a Russian threat actor it tracks\r\nas GruesomeLarch (publicly known as APT28, Forest Blizzard, Sofacy, Fancy Bear, among other\r\nnames). Volexity further determined that GruesomeLarch was actively targeting Organization A in order to collect\r\ndata from individuals with expertise on and projects actively involving Ukraine.\r\nThe month-and-a-half long investigation revealed that GruesomeLarch was able to ultimately breach Organization\r\nA’s network by connecting to their enterprise Wi-Fi network. The threat actor accomplished this by daisy-chaining\r\ntheir approach to compromise multiple organizations in close proximity  to their intended target, Organization A.\r\nThis was done by a threat actor who was thousands of miles away and an ocean apart from the victim. Volexity is\r\nunaware of any terminology describing this style of attack and has dubbed it the Nearest Neighbor Attack.\r\nThe Nearest Neighbor Attack\r\nGiven the assumed physical distance, you may be wondering how exactly this threat actor was able to authenticate\r\nto Organization A’s Enterprise Wi-Fi network. The first and most obvious thing needed were valid credentials.\r\nThis was accomplished via password-spray attacks against a public-facing service on Organization A’s network to\r\nvalidate credentials. And while credentials could be validated, they could not be used against Organization A’s\r\npublic services due to implementation of multi-factor authentication (MFA).\r\nThe Enterprise Wi-Fi network, however, did not require MFA and only required a user’s valid domain username\r\nand password to authenticate. Meanwhile, the threat actor was halfway around the world and could not actually\r\nconnect to Organization A’s Enterprise Wi-Fi network. To overcome this hurdle, the threat actor worked to\r\ncompromise other organizations who were in buildings within close proximity to Organization A’s office. Their\r\nstrategy was to breach another organization, and then move laterally within that organization to find systems they\r\ncould access that were dual-homed, (i.e., having both a wired and wireless network connection).\r\nOnce successful in this endeavor, having found a system that was connected to the network via a wired Ethernet\r\nconnection, the threat actor would access the system and use its Wi-Fi adapter. At this point they would connect to\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 1 of 10\n\nthe SSID of Organization A’s Enterprise Wi-Fi and authenticate to it, thus granting them access to Organization\r\nA’s network.\r\nThe anatomy of the Nearest Neighbor Attack is shown below.\r\nAt this point it would be understandable if you’re thinking this sounds a little far-fetched. However, Volexity\r\ndiscovered that GruesomeLarch was successful in breaching more than one organization within close proximity to\r\nOrganization A. And they were able to find and compromise a dual-homed system at a nearby organization,\r\nallowing them to connect to Organization A’s Enterprise Wi-Fi network from that compromised system.\r\nVolexity believes this represents a new class of attack that has not previously been described, in which a threat\r\nactor compromises one organization and performs credential-stuffing attacks in order to compromise other\r\norganizations in close physical proximity via their Wi-Fi networks. To reiterate, the compromise of these\r\ncredentials alone did not yield access to the customer’s environment, as all Internet-facing resources required use\r\nof multi-factor authentication (MFA). However, the Wi-Fi network was not protected by MFA, meaning proximity\r\nto the target network and valid credentials were the only requirements to connect.\r\nThis blog post aims to shed light on the tactics, techniques, and procedures (TTPs) Volexity observed during its\r\nincident investigation, and to provide a detailed look at how the Nearest Neighbor Attack worked and ways to\r\nmitigate against it.\r\nA Glimpse of a Ghost\r\nThis story begins on February 4, 2022, when Volexity detected suspicious activity on the network of its customer,\r\nOrganization A. This detection came after the triggering of an alert from a custom signature Volexity had\r\ndeveloped to look for files being written to and executed out of the root of the C:\\ProgramData directory. As\r\nVolexity investigated, it could see the following activity had occurred:\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 2 of 10\n\nA file named C:\\ProgramData\\servtask.bat had been written and executed.\r\nA file named servtask.bat had invoked the Microsoft command-line registry utility and PowerShell to run\r\nthe following commands:\r\nreg save hklm\\sam C:\\ProgramData\\sam.save\r\nreg save hklm\\security C:\\ProgramData\\security.save\r\nreg save hklm\\system C:\\ProgramData\\system.save\r\nPowershell -c “Get-ChildItem C:\\ProgramData\\sam.save, C:\\ProgramData\\security.save,\r\nC:\\ProgramData\\system.save ^| Compress-Archive -DestinationPath C:\\Program\\Dataout.zip”\r\nThis immediately put the Volexity threat detection \u0026 response team on high alert, as they could see sensitive\r\nregistry hives were being exported and compressed into a ZIP file. The next steps in the investigation were now\r\nclear: the team immediately expanded their deep dive into the system’s EDR event history and prepared a package\r\nto deploy Volexity Surge Collect Pro to collect system memory (RAM) and key disk artifacts.\r\nThe review of the EDR logs provided some interesting insight into activities that immediately preceded and came\r\nshortly after the initial finding. Volexity found the following had occurred on the system just ahead of the activity\r\nmentioned above:\r\nA login with an unprivileged user account on the server occurred over RDP.\r\nA file named DefragmentSrv.zip appeared on the system under that user’s directory and was unarchived\r\nusing the GUI version of WinRAR that was on the system.\r\nTwo files, DefragmentSrv.exe and DefragmentSrv.bat, were also written and executed; that chain\r\nultimately led to the writing and execution of servtask.bat.\r\nA file named wayzgoose52.dll was also written to a bogus directory located at\r\nC:\\ProgramDataA\\dobev3.80.15456.\r\nVolexity was keen to collect these files as part of the incident response investigation. Unfortunately, the team\r\nencountered two major issues. The first issue was that, in the middle of collecting system memory, the system was\r\nshut down. This was less than ideal, as it resulted in the loss of volatile data that may have proven useful to the\r\ninvestigation. It is possible components of those files would have still been memory resident and allowed their\r\nrecovery and analysis. Despite this setback, Volexity was able to have the server powered back on and still\r\ncollected forensics artifacts to support the investigation. However, the second issue was that Volexity found the\r\nattacker had removed all the files and folders that had been identified. Not only were the files gone, but Volexity\r\ndiscovered the attacker had run a native Microsoft utility called Cipher.exe , which covered their tracks by\r\nsecurely erasing the files. While this is not the first time Volexity has encountered an attacker covering their tracks\r\nwith anti-forensics methods, it is the first time Volexity had seen it done with the Cipher.exe utility.\r\nInvestigation Dead Ends\r\nAfter the initial incident, the attacker laid low for a while. In the meantime, Volexity used various forensic artifacts\r\nit collected to continue its investigation. Some challenges were encountered in the process. First, Volexity was\r\nable to identify an IP address that had connected to the victim server, but it was not immediately clear what it was\r\nrelated to, and it was no longer online. Further, Volexity had a network security sensor deployed in Organization\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 3 of 10\n\nA’s office, but there was virtually no record of the attacker on it. A few steps that would often immediately provide\r\nclarity and next steps in an investigation were frustratingly coming up empty.\r\nThe investigation went cold for a period of time before the attacker resurfaced. When the attacker returned,\r\nVolexity was able to get some answers. Volexity learned the IP address segment the attacker was coming from was\r\nassociated with Organization A’s Enterprise Wi-Fi network, and one of the domain controllers on the network\r\nacted as a DHCP server. However, after examining the DHCP logs, there was no record of the IP addresses\r\nVolexity had tied to the attacker. Another possible lead was another dead end.\r\nWireless Redemption\r\nA bit further into the investigation, Volexity learned the organization had a wireless controller that was used to\r\nmanage its wireless network, access points, and all related infrastructure. This controller also kept detailed logs\r\nrelated to signal strength, connected devices, authenticated user accounts, and so on. Volexity obtained access to\r\nthe wireless controller and had its first major break in the investigation. Not long after getting access to the\r\nwireless controller, Volexity was able to find the IP address of the attacker and tie it to an authenticated domain\r\nuser and a MAC address.\r\nArmed with this new information, Volexity was able to examine Organization A’s RADIUS logs and find\r\nauthentication events tied to the user and MAC address that had just been discovered. This same MAC address\r\nand user account appeared in older logs overlapping with the initial breach. However, Volexity found additional\r\nauthentication events with the same MAC address and a different username going back to late January 2022.\r\nVolexity learned the password for the account observed from January had expired and been updated by the user.\r\nThis apparently locked the attacker out of that account, but they were able to come back in early February with the\r\naccount observed from the wireless controller.\r\nThis new information caused Volexity to examine logs from a system at Organization A that provided Internet-facing webservices that could be authenticated against. The service itself was protected with MFA, but it could be\r\nused to verify if credentials were valid or not. Upon examining those logs, Volexity found that in January and\r\nFebruary, password-spray attacks had been carried out against this service and three accounts had been\r\nsuccessfully compromised by an attacker. Two of the three accounts identified were those Volexity had identified\r\nfrom the wireless controller and RADIUS logs. The third account had not yet been used.\r\nVolexity now determined the attacker was connecting to the network via wireless credentials they had brute-forced\r\nfrom an Internet-facing service. However, it was not clear where the attacker was physically that allowed them to\r\nconnect to the Enterprise Wi-Fi to begin with. Further analysis of data available from Organization A’s wireless\r\ncontroller showed which specific wireless access points the attacker was connecting to and overlayed them on a\r\nmap that had a layout of the building and specific floors. Volexity could see the attacker was connecting to the\r\nsame three wireless access points that were in a conference room at the far end of the building near windows along\r\nthe street. This gave Volexity the first evidence that the “call was not coming from inside the building.” Could this\r\nbe an attacker conducting a close access operation from the street outside? Nothing was ruled out, but Volexity\r\nwas not too far off from discovering the real answer.\r\nTrust No One, Especially Your Neighbor\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 4 of 10\n\nDuring the course of this investigation, Volexity worked with Organization A to take various remediation steps,\r\nimplement countermeasures, and make improvements to various areas where logging and network visibility were\r\nnot optimal. Doing this ultimately allowed Volexity to make a huge break in the investigation and figure out\r\nexactly what was going on.\r\nDespite resetting various credentials, including the three accounts identified from the password-spray attacks, the\r\nattacker still had working domain credentials. The attacker once again regained access to the Organization A’s\r\nEnterprise Wi-Fi, but with visibility and logging now in place, Volexity quickly jumped into action. Volexity was\r\nnow able to pull full packet capture from all activity involving Wi-Fi connected systems in Organization A’s\r\nnetwork, regardless of where they connected internally. Analysis of this packet capture revealed the attacker’s\r\nsystem had sent out NetBIOS Name Service (NBNS) queries that revealed its computer name and the active\r\ndirectory domain to which it was joined. This active directory domain revealed exactly where the attacker was\r\nconnecting from, which turned out to be an organization (“Organization B”) located right across the street.\r\nVolexity was able to get in touch with Organization B and work with them to investigate this matter further. This\r\nis where Volexity ultimately uncovered how the attacker was operating, and how the Nearest Neighbor Attack\r\nworked. In coordination with Organization B, Volexity was able to find the system that had connected to\r\nOrganization A’s Wi-Fi. Analysis of this system showed it had been breached after an attacker used privileged\r\ncredentials to connect to it via RDP from another system within Organization B’s network. This system was dual-homed and connected to the Internet via wired Ethernet, but it also had a Wi-Fi network adapter that could be used\r\nat the same time. The attacker found this system and used a custom PowerShell script to examine the available\r\nnetworks within range of its wireless, and then connected to Organization A’s Enterprise Wi-Fi using credentials\r\nthey had compromised. A redacted copy of the C# code embedded in the custom PowerShell script is available\r\nhere.\r\nAdditional analysis of systems at Organization B revealed the intruder had two modes of access to their network.\r\nThe first was with credentials that allowed them to connect to their VPN, which was not protected with MFA.\r\nVolexity also found evidence the attacker had been connecting to Organization B’s Wi-Fi from another network\r\nthat belonged to another nearby organization (“Organization C”). The attacker had gone to great lengths to breach\r\nmultiple organizations so they could daisy-chain Wi-Fi and/or VPN connections to ultimately reach the network of\r\nOrganization A. The team at Volexity was astounded but also breathed a sigh of relief that it now had an\r\nexplanation and evidence of how this attack was happening.\r\nVolexity was able to determine who Organization C was based on analysis of MAC addresses and SSID\r\ninformation and contacted them. However, Organization C opted not to provide Volexity with access to key data\r\nrequired to take the investigation further. In any case, all of these findings gave Volexity a full understanding of\r\nthe attacker’s operations and allowed the team to confidently recommend further mitigations and remediation\r\ninstructions to Organization A. At this point the attacker’s access was cut off from Organization A’s Enterprise Wi-Fi, and they have not been observed connecting to this network since then.\r\nOne Final Hurrah: The Guest Wi-Fi\r\nOver a month after the last observed threat actor activity, and following various remediation steps, Volexity had\r\nyet another alert indicating suspect activity in the network of its customer, Organization A. Upon investigating that\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 5 of 10\n\nactivity, Volexity discovered the same threat actor had managed to return to the network and was proxying through\r\nmultiple internal systems. Fortunately, Volexity was able to rapidly investigate this incident and walk it back\r\nthrough multiple systems to its origin: a system on Organization A’s Guest Wi-Fi network.\r\nWhile the Guest Wi-Fi network had been believed to be completely isolated from the corporate wired network,\r\nwhere the high-value targeted data resided, there was one system that was accessible from both the Wi-Fi network\r\nand the corporate wired network. Armed with the credentials of an account that had not been reset, and the fact\r\nthat the Wi-Fi network was not completely isolated, the attacker was able to pivot back into the corporate wired\r\nnetwork and ultimately regain access to the high-value targeted data.\r\nTo achieve this pivot, the attacker used the Windows utility netsh to set up a series of port-forwards that allowed\r\nthem to reach the target systems. Example commands used for this are provided below:\r\ncmd.exe /C netsh advfirewall firewall add rule name=\"Remote Event Log Management SMB\"\r\ndir=in action=allow protocol=tcp localport=12345 \u003e C:\\Windows\\Temp\\MSI28122Ac.LOG 2\u003e\u00261\r\ncmd.exe /C netsh interface portproxy add v4tov4 listenaddress=172.33.xx.xx listenport=12345\r\nconnectaddress=172.20.xx.xx connectport=445 \u003e C:\\Windows\\Temp\\MSI2cBfA24.LOG 2\u003e\u00261\r\nThe source system connecting in to instigate this activity could once again be determined through analysis of\r\nnetwork traffic and logs from Organization A’s wireless controller. Volexity found that the attacker was connecting\r\nin this time from Organization C. Volexity again contacted Organization C and also worked with Organization A\r\nto take new remediation steps to resolve this new intrusion.\r\nSince this final activity related to the Guest Wi-Fi network, there has been no observed activity that Volexity can\r\ntie to an attacker leveraging the Nearest Neighbor Attack.\r\nTradecraft Notes\r\nGruesomeLarch predominantly adopted a living-off-the-land approach during their intrusion, leveraging standard\r\nMicrosoft protocols and moving laterally. The sections that follow detail some observations from the incident that\r\ncould be used to potentially detect GruesomeLarch or other threat actors using similar behaviors or techniques.\r\nUse of Cipher.exe\r\nDuring the intrusion, the attacker removed files they created, making use of an inbuilt Windows tool,\r\nCipher.exe , that ships with every modern version of Windows:\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 6 of 10\n\nThe following functionality was used to overwrite deleted data in a particular folder:\r\ncmd.exe /c cipher /W:C\r\nThe Microsoft documentation describes this in the following way:\r\nThe effect is that attackers are able to securely delete their tools using native Windows functionality without\r\nbringing a new tool or writing their own code, thus making recovery of attacker tools more difficult for forensic\r\nanalysts.\r\nThe attacker in this case was meticulous in their use of this tool, with every file that Volexity identified as having\r\nbeen written to disk being later deleted by this tool. It is worth noting that in its numerous incident response\r\nengagements, Volexity has not previously identified an attacker cleaning up after themselves using this technique.\r\nDumping Ntds.dit via VSSAdmin\r\nAnother observed tactic was the attempt to steal the active directory database by creating a volume shadow copy.\r\nThis is a common technique and one that Volexity has seen for several years. The workflow is well documented\r\npublicly and consists of the following key components that were seen in this incident:\r\nCreate a volume shadow copy, e.g., the following:\r\nvssadmin create shadow /for C: /quiet\r\nRetrieve a copy of the ntds.dit file and the SYSTEM registry hive from the volume shadow copy:\r\ncopy \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\NTDSNTDS.dit [dest]\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 7 of 10\n\ncopy \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\System32\\config\\SYSTEM [dest]\r\nDownload the copied files. To download the files (which were fairly large) the attacker compressed them\r\nusing a PowerShell command:\r\npowershell -c \"\u0026 { Add-Type -Assembly 'System.IO.Compression.FileSystem';\r\n[IO.Compression.ZipFile]::CreateFromDirectory($path1', '$path2');}\" \u003e\r\nC:\\Windows\\Temp\\b2rMBPL.tmp 2\u003e\u00261\r\nAntivirus and endpoint detection and response (EDR) products may naturally detect this behavior as being\r\npotentially malicious. However, for additional detection opportunities, organizations can create custom EDR\r\nsignatures to look for a privileged account which exhibits the following:\r\nAny use of vssadmin.exe\r\nCopying or moving of files from the VolumeShadowCopy directories\r\nPowerShell commands indicating in-line compression of files\r\nStaging Data for Exfiltration\r\nThe majority of the data from this incident was copied back to the attacker’s system, which was connected to the\r\nWi-Fi. However, in a few cases, Volexity observed the attacker staging data in directories on a public-facing\r\nwebserver. These files were then exfiltrated via external downloads.\r\nThis is a common technique that Volexity sees attackers use in a variety of breaches. It can be difficult to monitor\r\nfor this activity, but there are opportunities to detect this behavior if organizations can monitor for unexpected files\r\non webservers or large file transfers that are out of the ordinary. If nothing else, ensuring web logs are working\r\nand being saved can assist with investigations later on.\r\nAttribution\r\nInitially, Volexity was not able to attribute this intrusion to a known threat actor. The attacker was largely using\r\nliving-off-the-land techniques, and any tooling or IP addresses they used made it difficult for Volexity to zero in\r\non a possible culprit. However, once Volexity was able to determine who and what was being targeted internally, it\r\nimmediately suspected that this was the activity of a Russian threat actor, but which one?\r\nThen, in April 2024, Microsoft published research on Forest Blizzard, which Volexity tracks as GruesomeLarch,\r\ndetailing a post-compromise tool named GooseEgg that the threat actor had used. This tool was leveraged in the\r\nzero-day exploitation of CVE-2022-38028, a privilege escalation vulnerability in the Microsoft Windows Print\r\nSpooler service. In their report, Microsoft detailed several key file names, folder paths, and commands used by the\r\nframework, notably the following:\r\nServtask.bat\r\nWayzgoose52.dll\r\nDefragmentSrv.exe\r\nC:\\ProgramData\\[var]\\v%u.%02u.%04u\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 8 of 10\n\nThese exact file names and paths were observed in the incident investigated by Volexity. Microsoft’s report also\r\nshowed what commands were in the servtask.bat file, which were identical to what Volexity had seen where\r\nregistry hives had been saved and compressed into a file named out.zip from the initial intrusion activity.\r\nHowever, as documented in the Tradecraft Notes section of this blog post, these files had been securely deleted\r\nusing the Cipher.exe tool.\r\nMicrosoft’s post stated that GooseEgg had been in use since “at least June 2020 and possibly as early as April\r\n2019.” Volexity can confirm this tool was definitively used in February 2022. Exploitation of CVE-2022-38028\r\nalso provides an explanation as to how the initial victim system was likely compromised. Based on the use of this\r\ntool, which Microsoft indicates is unique to this threat actor, Volexity assesses with high confidence that the\r\nactivity described in this post can be attributed to GruesomeLarch.\r\nConclusion\r\nVolexity’s investigation reveals the lengths a creative, resourceful, and motivated threat actor is willing to go to in\r\norder to achieve their cyber-espionage objectives. The Nearest Neighbor Attack effectively amounts to a close\r\naccess operation, but the risk of being physically identified or detained has been removed. This attack has all the\r\nbenefits of being in close physical proximity to the target, while allowing the operator to be thousands of miles\r\naway.\r\nOrganizations need to place additional considerations on the risks that Wi-Fi networks may pose to their\r\noperational security. A significant amount of effort over the last several years has been placed on attack surface\r\nreduction where Internet-facing services have been secured with MFA or removed altogether. However, the same\r\nlevel of care has not necessarily been given to Wi-Fi networks. It may be time to treat access to corporate Wi-Fi\r\nnetworks with the same care and attention that other remote access services, such as virtual private networks\r\n(VPNs), have received.\r\nThis attack was possible due to a lower level of security controls on targeted Wi-Fi systems than other resources,\r\nsuch as email or VPN. In this case, an attacker figured out how to abuse these controls, even though they were far\r\nbeyond their geographic reach, using the following workflow:\r\nCompromise an organization in the physical geographic vicinity of their target.\r\nFind a dual-homed system in that network, which has both Ethernet and Wi-Fi connectivity.\r\nExamine the available Wi-Fi networks within reach of the compromised, dual-homed system being\r\naccessed.\r\nBrute-force credentials for organizations related to those Wi-Fi networks.\r\nAuthenticate to physically adjacent Wi-Fi networks using discovered credentials.\r\nUsing the Nearest Neighbor Attack method, the attacker was able to daisy-chain their way from organization to\r\norganization without ever deploying malware, using only valid user credentials as their access method. The\r\nattacker then focused on using living-of-the-land techniques to avoid deploying malware and to evade detection\r\nby EDR products.\r\nTo generally prevent or detect attacks similar to those discussed in this blog, Volexity recommends the following:\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 9 of 10\n\nMonitor and alert on anomalous use of the netsh and Cipher.exe utilities within your environment.\r\nCreate custom detection rules to look for files executing from various non-standard locations, such as the\r\nroot of C:\\ProgramData\\.\r\nDetect and identify exfiltration of data from Internet-facing services run in your environment.\r\nCreate separate networking environments for Wi-Fi and Ethernet-wired networks, particularly where\r\nEthernet-based networks allow for access to sensitive resources.\r\nConsider hardening access requirements for Wi-Fi networks, such as applying MFA requirements for\r\nauthentication or certificate-based solutions.\r\nMonitor network traffic between devices to identify files being transferred via SMB that contain commonly\r\nexfiltrated data (credential data, ntds.dit, registry hives, etc.).\r\nAcknowledgement\r\nVolexity would like to thank its customer for granting permission to publicly share information about this\r\ninvestigation.\r\nSource: https://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-cove\r\nrt-access/\r\nhttps://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MISPGALAXY", "ETDA", "MITRE" ], "references": [ "https://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/" ], "report_names": [ "the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access" ], "threat_actors": [ { "id": "730dfa6e-572d-473c-9267-ea1597d1a42b", "created_at": "2023-01-06T13:46:38.389985Z", "updated_at": "2026-04-10T02:00:02.954105Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "Pawn Storm", "ATK5", "Fighting Ursa", "Blue Athena", "TA422", "T-APT-12", "APT-C-20", "UAC-0001", "IRON TWILIGHT", "SIG40", "UAC-0028", "Sofacy", "BlueDelta", "Fancy Bear", "GruesomeLarch", "Group 74", "ITG05", "FROZENLAKE", "Forest Blizzard", "FANCY BEAR", "Sednit", "SNAKEMACKEREL", "Tsar Team", "TG-4127", "STRONTIUM", "Grizzly Steppe", "G0007" ], "source_name": "MISPGALAXY:APT28", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e3767160-695d-4360-8b2e-d5274db3f7cd", "created_at": "2022-10-25T16:47:55.914348Z", "updated_at": "2026-04-10T02:00:03.610018Z", "deleted_at": null, "main_name": "IRON TWILIGHT", "aliases": [ "APT28 ", "ATK5 ", "Blue Athena ", "BlueDelta ", "FROZENLAKE ", "Fancy Bear ", "Fighting Ursa ", "Forest Blizzard ", "GRAPHITE ", "Group 74 ", "PawnStorm ", "STRONTIUM ", "Sednit ", "Snakemackerel ", "Sofacy ", "TA422 ", "TG-4127 ", "Tsar Team ", "UAC-0001 " ], "source_name": "Secureworks:IRON TWILIGHT", "tools": [ "Downdelph", "EVILTOSS", "SEDUPLOADER", "SHARPFRONT" ], "source_id": "Secureworks", "reports": null }, { "id": "ae320ed7-9a63-42ed-944b-44ada7313495", "created_at": "2022-10-25T15:50:23.671663Z", "updated_at": "2026-04-10T02:00:05.283292Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "APT28", "IRON TWILIGHT", "SNAKEMACKEREL", "Group 74", "Sednit", "Sofacy", "Pawn Storm", "Fancy Bear", "STRONTIUM", "Tsar Team", "Threat Group-4127", "TG-4127", "Forest Blizzard", "FROZENLAKE", "GruesomeLarch" ], "source_name": "MITRE:APT28", "tools": [ "Wevtutil", "certutil", "Forfiles", "DealersChoice", "Mimikatz", "ADVSTORESHELL", "Komplex", "HIDEDRV", "JHUHUGIT", "Koadic", "Winexe", "cipher.exe", "XTunnel", "Drovorub", "CORESHELL", "OLDBAIT", "Downdelph", "XAgentOSX", "USBStealer", "Zebrocy", "reGeorg", "Fysbis", "LoJax" ], "source_id": "MITRE", "reports": null }, { "id": "d2516b8e-e74f-490d-8a15-43ad6763c7ab", "created_at": "2022-10-25T16:07:24.212584Z", "updated_at": "2026-04-10T02:00:04.900038Z", "deleted_at": null, "main_name": "Sofacy", "aliases": [ "APT 28", "ATK 5", "Blue Athena", "BlueDelta", "FROZENLAKE", "Fancy Bear", "Fighting Ursa", "Forest Blizzard", "G0007", "Grey-Cloud", "Grizzly Steppe", "Group 74", "GruesomeLarch", "ITG05", "Iron Twilight", "Operation DealersChoice", "Operation Dear Joohn", "Operation Komplex", "Operation Pawn Storm", "Operation RoundPress", "Operation Russian Doll", "Operation Steal-It", "Pawn Storm", "SIG40", "Sednit", "Snakemackerel", "Sofacy", "Strontium", "T-APT-12", "TA422", "TAG-0700", "TAG-110", "TG-4127", "Tsar Team", "UAC-0028", "UAC-0063" ], "source_name": "ETDA:Sofacy", "tools": [ "ADVSTORESHELL", "AZZY", "Backdoor.SofacyX", "CHERRYSPY", "CORESHELL", "Carberp", "Computrace", "DealersChoice", "Delphacy", "Downdelph", "Downrage", "Drovorub", "EVILTOSS", "Foozer", "GAMEFISH", "GooseEgg", "Graphite", "HATVIBE", "HIDEDRV", "Headlace", "Impacket", "JHUHUGIT", "JKEYSKW", "Koadic", "Komplex", "LOLBAS", "LOLBins", "Living off the Land", "LoJack", "LoJax", "MASEPIE", "Mimikatz", "NETUI", "Nimcy", "OCEANMAP", "OLDBAIT", "PocoDown", "PocoDownloader", "Popr-d30", "ProcDump", "PythocyDbg", "SMBExec", "SOURFACE", "SPLM", "STEELHOOK", "Sasfis", "Sedkit", "Sednit", "Sedreco", "Seduploader", "Shunnael", "SkinnyBoy", "Sofacy", "SofacyCarberp", "SpiderLabs Responder", "Trojan.Shunnael", "Trojan.Sofacy", "USB Stealer", "USBStealer", "VPNFilter", "Win32/USBStealer", "WinIDS", "Winexe", "X-Agent", "X-Tunnel", "XAPS", "XTunnel", "Xagent", "Zebrocy", "Zekapab", "carberplike", "certutil", "certutil.exe", "fysbis", "webhp" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434657, "ts_updated_at": 1775792270, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/093ef4e54c487b33a0b83aef95f8749ae4a511b3.pdf", "text": "https://archive.orkl.eu/093ef4e54c487b33a0b83aef95f8749ae4a511b3.txt", "img": "https://archive.orkl.eu/093ef4e54c487b33a0b83aef95f8749ae4a511b3.jpg" } }