{
	"id": "194e5330-0ca0-4a86-b1db-bc4a16adab90",
	"created_at": "2026-04-17T02:20:27.574636Z",
	"updated_at": "2026-04-18T02:21:27.682621Z",
	"deleted_at": null,
	"sha1_hash": "e94c0d98494a122e3438171f0e3a2aca87b3d1e2",
	"title": "UPSynergy: Chinese-American Spy vs. Spy Story",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 155186,
	"plain_text": "UPSynergy: Chinese-American Spy vs. Spy Story\r\nBy Yaroslav Harakhavik\r\nPublished: 2019-09-05 · Archived: 2026-04-17 02:11:51 UTC\r\nResearch By: Mark Lechtik \u0026 Nadav Grossman\r\nIntroduction\r\nEarlier this year, our colleagues at Symantec uncovered an interesting story about the use of Equation group\r\nexploitation tools by an alleged Chinese group named Buckeye (a.k.a APT3, or UPS team). One of the key\r\nfindings in their publication was that variants of the Equation tools were used by the group prior to ‘The Shadow\r\nBrokers’ public leak in 2017. Moreover, it seems that APT3 developed its own in-house capabilities and equipped\r\nits attack tool with a 0-day that targeted the Windows operating system.\r\nFollowing these revelations, we decided to expand on Symantec’s findings and take a deeper look at Bemstour, the\r\ngroup’s exploitation tool. In our analysis, we try to understand the background environment in which it was\r\ncreated, and provide our perspective of how it was developed. Our observations from the technical analysis allow\r\nus to provide evidence for a speculation that was formerly suggested by Symantec – APT3 recreated its own\r\nversion of an Equation group exploit using captured network traffic. We believe that this artifact was collected\r\nduring an attack conducted by the Equation group against a network monitored by APT3, allowing it to enhance\r\nits exploit arsenal with a fraction of the resources required to build the original tool.\r\nAPT3 is known to be a long-standing and sophisticated threat actor, having a record of using advanced TTPs, such\r\nas leveraging zero day exploits in its attacks. Such capabilities are consistent with former research by Intrusion\r\nTruth and Recorded Future, stating that the entity behind APT3 is the Chinese Ministry of State Security. That\r\nsaid, it wasn’t very clear so far whether the group developed its exploits in-house or acquired them elsewhere. In\r\nthis publication we deliver a glance into one possible modus operandi – the Chinese collect attack tools used\r\nagainst them, reverse engineer and reconstruct them to create equally strong digital weapons.\r\nFollowing is a summary of our key findings:\r\nThe group’s exploitation tool named Bemstour makes use of a variant of a single Equation group exploit.\r\nOur research shows that the particular equivalent to this exploit is EternalRomance. APT3 developed their\r\nown implementation, possibly based on their analysis and understanding of EternalRomance’s leveraged\r\nvulnerability.\r\nThe group attempted to develop the exploit in a way that allowed it to target more Windows versions,\r\nsimilar to what was done in a parallel Equation group exploit named EternalSynergy. This required looking\r\nfor an additional 0-day that provided them with a kernel information leak. All of this activity suggests that\r\nthe group was not exposed to an actual NSA exploitation tool, as they would then not need to create\r\nanother 0-day exploit. We decided to name APT3’s bundle of exploits UPSynergy, since, much like in the\r\ncase of Equation group, it combines 2 different exploits to expand the support to newer operating systems.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 1 of 25\n\nThe underlying SMB packets used throughout the tool execution were crafted manually by the developers,\r\nrather than generated using a third party library. As a lot of these packets were assigned with hardcoded and\r\nseemingly arbitrary data, as well as the existence of other unique hardcoded SMB artifacts, we can assume\r\nthat the developers were trying to recreate the exploit based on previously recorded traffic.\r\nIf network traffic was indeed used by the group as a reference, the traffic was likely collected from a\r\nmachine controlled by APT3. This means either a Chinese machine that was targeted by the NSA and\r\nmonitored by the group, or a machine compromised by the group beforehand on which foreign activity was\r\nnoticed. We believe the former is more likely, and in that case could be made possible by capturing lateral\r\nmovement within a victim network targeted by the Equation group.\r\nFinding a 0-day info leak, recreating the exploit based on the aforementioned vulnerability, and utilizing a\r\nlot of internal undocumented structures of SMB in the implants, implies that there was a similar expertise\r\nwith and analysis performed on SMB drivers (with an eye to exploiting them) on the Chinese side, roughly\r\nat the same time it was widely used by the NSA. This, to some extent, suggests a narrative where China\r\nand the US are engaged in a cyber arms race to develop new exploits.\r\nIn the following sections, we provide the technical basis for our conclusions, by taking a tour through the tool’s\r\ninternals, its underlying exploit, and the implant’s nuts and bolts. We also dive deeply into  the root cause for the\r\n0-day found by APT3. To the best of our knowledge, this hasn’t been described anywhere else.\r\nOverview of the Bemstour Tool\r\nBesmtour is a tool developed by APT3 to gain remote code execution on a victim’s machine using UPSynergy – a\r\ncombination of an exploit based on EternalRomance and a 0-day found by the group itself. The goal is to deploy a\r\npayload on the victim’s machine which is injected to a running process using an implant. This implant is highly\r\nsimilar to the Equation group’s DoublePulsar.\r\nThe tool is meant to be run from a command line, and provides 2 modes of operation. In the first, the attacker\r\nsends a local file which will be executed on the victim machine with a given command line argument. In the 2nd\r\nmode, the attacker runs an arbitrary shell command without the need to send an actual file.\r\nThese functionalities are supported in both 32 and 64 bit versions. According to Symantec, the 64 bit versions\r\nwere leveraged solely for executing shell commands, mostly to generate new user accounts in the victims’\r\nenvironments.\r\nFigure 1: The 2 modes of operation provided by Bemstour.\r\nOne thing we noted about Bemstour’s code is the way it generates and sends traffic to the victim’s machine. In\r\nparticular, we noticed that all packets are built manually, i.e. the developers created structs to represent the various\r\nSMB packets to send to the victim, and issued them over plain TCP sockets.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 2 of 25\n\nFigure 2: An example of a manually constructed SMB header.\r\nAs part of the manual crafting of SMBs, the developers assigned them with values hardcoded in the binary. Some\r\nof these reside within the data section in the form of custom structs, such as the one depicted in the figure below.\r\nWhen such a hardcoded assignment is required, an allocated SMB and the hardcoded structure are issued as\r\narguments to a specific function, which in turn takes the custom struct’s field values and assigns them to the\r\ncorresponding SMB fields.\r\nFigure 3: A custom structure containing fields to populate SMB headers with hardcoded values.\r\nWhen looking at a structure like this, it’s noteworthy that some of its fields represent unique values that are\r\ngenerated per SMB connection. One such value is the UID, which can be declared by the client and therefore\r\ncould be chosen arbitrarily by Bemstour. In this case, there are multiple instances where this field is given\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 3 of 25\n\nhardcoded unique values in a particular range, which may hint that they were copied from a source like recorded\r\nnetwork traffic.\r\nFigure 4: Instances of the custom hardcoded SMB header structure.\r\nWe found other hardcoded structures that are actually not used in any place in the code, but whose values and\r\norder imply the field they represent. This suggests that these are header fragments that were left as residues in the\r\nbinary from another source. An example of such structs is shown below, where a numeric proximity can be seen to\r\nthose UIDs that are used in the code.\r\nFigure 5: Unused fragments of SMB header that are left in the binary.\r\nThere are additional hardcoded artifacts that may provide some insight into the tool’s nature. For example, the\r\nPDB path (seen in the figure below) points out that the tool’s source name is “SMB Master”, and it was part of a\r\nproject called “SMB_FOR_ALL_Ultimate-signature.” Based on this, we can speculate that the project was indeed\r\nabout repurposing an SMB exploit to target “ALL” (or at least more) versions of Windows.\r\nFigure 6: PDB path hardcoded in the tool’s binary.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 4 of 25\n\nFinally, more unused strings show something that looks like a concatenation of a computer name, user name and\r\nperhaps domain name. It is unclear where they come from, but again, strengthens the idea that this network entity\r\nwas part of a referenced traffic capture.\r\nFigure 7: Unused strings that reveal a network entity.\r\nOverview of the Eternal* Exploits\r\nBefore we take a further look at the details of APT3’s exploit implementation, we need to understand the various\r\nEternal exploits that were incorporated into the Lost in Translation leak by The Shadow Brokers. Back in 2017,\r\nwhen this leak was released, 4 Eternal exploits were uncovered: EternalBlue, EternalChampion, EternalRomance\r\nand EternalSynergy.\r\nBoth   and EternalRomance targeted mostly Windows 7 systems (as well as lower version of Windows NT where\r\nSMBv1 is located). One of the problems in adapting EternalRomance to higher Windows versions was a patch\r\nintroduced in Windows 8 which eliminated the possibility to use an information leak vulnerability leveraged by it.\r\nTo deal with this problem, the Equation group came up with an upgraded version where the problematic info leak\r\nwas replaced with one that could be exploited on Windows 8. Essentially, there was nothing new there, as the info\r\nleak exploit was already used in EternalChampion and other parts of EternalRomance remained the same. This\r\nnew hybrid exploit was named EternalSynergy, suggesting the way it was built – a synergy of 2 exploits.\r\nWhen it comes to the exploit in the Bemstour tool, it is evident that there’s an attempt to leverage the same\r\nvulnerability exploited by EternalRomance. At the same time, there is the use of a whole new information leak\r\nexploit, which was in fact a 0-day found by APT3. As we will see in the upcoming section, this particular\r\ninformation leak is quite robust and allowed the group to upgrade their version of EternalRomance to use in\r\nversions higher than Windows 7.\r\nIn this sense, APT3 crafted its own exploit from other exploits – a tactic very similar to one used by the Equation\r\ngroup. As this threat group also uses the name UPS team, we decided to name their version of the exploit bundle\r\nUPSynergy.\r\nRoot Cause Analysis of CVE 2019-0703\r\nAccording to Microsoft, CVE-2019-0703 is “an information disclosure vulnerability [that] exists in the way […]\r\nthe Windows SMB Server handles certain requests. An authenticated attacker who successfully exploited this\r\nvulnerability could craft a special packet, which could lead to information disclosure from the server.\r\nTo exploit the vulnerability, an attacker would have to be able to authenticate and send SMB messages to an\r\nimpacted Windows SMB Server The security update addresses the vulnerability by correcting how Windows SMB\r\nServer handles authenticated requests.”\r\nOur analysis shows a slightly different picture. The vulnerability is in fact a logical bug related to querying\r\ninformation from the Windows Named Pipes mechanism, and not a vulnerabilityin the SMB protocol nor its\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 5 of 25\n\nimplementation. While it can be triggered using SMB, there are other ways to leverage it, e.g. using the\r\nNtQueryInformationFile Windows API call that is unrelated to SMB.\r\nThe bug resides within npfs.sys (Name Pipe File System driver) in a function named NpQueryInternalInfo. The\r\nlatter is used to query named pipes and return a value called a file reference number, which according to\r\nMicrosoft  “MUST be assigned by the file system and is unique to the volume on which the file or directory is\r\nlocated.”\r\nHowever, our analysis shows that the returned value is not a file reference number, but rather a pointer to a kernel\r\nstructure named CCB (Client Control Block). This is an undocumented struct defined in npfs.sys, which has a\r\npartial definition (named NP_CCB) provided by the ReactOS project. Clearly, this is not the intended value to be\r\nreturned in this case, and the leak of this struct discloses useful information that can be leveraged by attackers.\r\nFigure 8: The leaked object is in fact a CCB struct, as evident from WinDbg.\r\nTo trigger this information disclosure vulnerability, a call with the following arguments is made to the\r\nNtQueryInformationFile stub in ntdll.dll:\r\nFileHandle – Handle to a named pipe (for example “\\\\.\\pipe\\browser”).\r\nFileInformationClass – FileInternalInformation (equals 0x6).\r\nAfter this happens, we get the following call stack:\r\nFigure 9: Kernel mode call stack corresponding to an NtQueryInformationFile call from user mode.\r\nAs already mentioned, it is also possible to trigger this vulnerability via SMB, as was used by APT3. The method\r\nwas used to determine the bitness of the attacked operating system and overwrite (using a write primitive) a field\r\nin the leaked structure, which eventually provided the group with remote code execution.\r\nTo leverage the vulnerability, you must first establish an SMB connection to a named pipe on the victim’s\r\nmachine, as can be seen in the figure below.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 6 of 25\n\nFigure 10: Network capture of SMB packets that demonstrates an establishment of a connection to the\r\n\\pipe\\browser named pipe (FID 0x4000).\r\nNext, it’s possible to query information about the opened pipe using the 0x32 SMB command\r\n(SMB_COM_TRANSACTION2) and the 0x7 subcommand (TRANS2_QUERY_FILE_INFORMATION). The\r\nlatter has a field named InformationLevel which describes the types of information that can be retrieved by the\r\nserver.\r\nFurthermore, if the server declared a capability named Infolevel Passthru in its Negotiate Response field as a part\r\nof an earlier negotiation (a capability usually provided by default), more types of information can be retrieved,\r\nnamely ones that provide native file information on the server. In this case, the former capability allows it to\r\nprovide a code number named a Pass-thru Information Level by the client, which maps directly to another\r\nWindows NT numerical value called an Information Class on the server. This value corresponds to the\r\nFileInformationClass parameter of the NtQueryInformationFile API, which specifies what type of file information\r\nto query from a server destined file object.\r\nTo use one of the pass-thru Information Levels to request a corresponding Information Class for a file on the\r\nserver, it is sufficient to add the value 0x3e8 (SMB_INFO_PASSTHROUGH) to the requested Information Class.\r\nAs an example, if we take the FileInternalInformation Information Class (which has the value 6) and want to get\r\nthe corresponding Information Level, we just need to add the previously mentioned value to it, resulting in the\r\nvalue 0x3ee.\r\nIn our case, using this very same Information Level by placing it as a parameter of the\r\nTRANS2_QUERY_FILE_INFORMATION subcommand, triggers the vulnerability by causing the invocation of\r\nthe NtQueryInformationFile from the srv.sys driver (SMB driver). The latter in turn calls the vulnerable\r\nNpQueryInternalInfo from npfs.sys, as depicted in the stack trace below.\r\nFigure 11: Kernel mode calls stack resulting from execution of the SMB transaction that triggers the bug.\r\nConsequently, when we issue a Trans2 request to query for a file info using the previously mentioned Info Level,\r\nwe get a CCB leaked pointer in the response.\r\nFigure 12:  Wireshark’s view of triggering the vulnerability.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 7 of 25\n\nTo examine the described root cause for the vulnerability from another angle, we can take a look at the diff\r\nbetween the patched and unpatched code in npfs.sys:\r\nFigure 13: Patch diff – The vulnerable code can be seen in the upper part.\r\nAs can be seen in the vulnerable code, the out_buffer argument returned to the caller and then to the client\r\ncontains a pointer to the ClientControlBlock (NP_CCB) argument instead of the file reference number. This is\r\nfixed in the patched code, where offsets 0xa0 and 0xa4 from ClientControlBlock are written to the out_buffer\r\ninstead, thus returning the actual intended file reference number to the caller and client.\r\nAs mentioned previously, the information obtained from this info leak can give us the ability to execute code on\r\nthe victim machine, using another write primitive. To understand how this is possible, we need to take a closer\r\nlook at the CCB structure. One of its members points to yet another undocumented struct, which we will denote as\r\n‘struct x’. This struct contains a pointer to a function that is called when the connection to the named pipe is\r\nterminated, which we’ll refer to as the ‘pipe destructor function’.\r\nIn APT3’s implementation of the exploit, the HAL heap is written with both shellcode and a rogue instance of\r\n‘struct x’. The latter simply contains a pointer to the shellcode in the position of the ‘pipe destructor function’.\r\nTherefore, when we use a write primitive and know the whereabouts of the leaked CCB structure, we can\r\noverwrite its pointer to ‘struct x’ so that it points to the rogue instance. After the connection is closed, the\r\nshellcode is triggered and the attacker can run arbitrary code on the victim’s machine.\r\nComparison of UPSynergy and Eternal Romance Implementations\r\nOne of the observations we made during our analysis of Bemstour was that its main exploit targets only a\r\nparticular vulnerability that overlaps with one used by the Equation group. This vulnerability is rooted in a type\r\nconfusion bug leveraged in a similar fashion in the EternalRomance exploit, which was then reused together with\r\nother exploits in EternalSynergy.\r\nAs a result of this type confusion between SMB messages, the server considers an unrelated SMB message as part\r\nof an SMB Transaction of a different type, and activates the wrong type of SMB handler. This handler in turn\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 8 of 25\n\nshifts the Transaction struct’s pointer to the incoming data buffer by the amount of data received in the SMB\r\nmessage. Because the pointer value was shifted by the wrong handler, data of further SMB messages (which are\r\ntreated by the correct type of handler) can be potentially written outside the boundaries of the incoming data\r\nbuffer. If there was successful grooming (i.e. the heap was correctly shaped beforehand), this out-of-bound write\r\nmay allow us to overwrite an adjacent SMB Transaction structure.\r\nInstead of going through every detail of APT3’s exploit, the table below compares the underlying techniques used\r\nby EternalRomance vs. those used by UPSynergy. Detailed information about the bug (CVE-2017-0143) and how\r\nit was exploited in EternalRomance to gain a write-what-where and read-what-where primitives is explained very\r\nwell by Microsoft in their analysis of EternalSynergy.\r\nExploitation\r\nTechnique\r\nEternalRomance APT3 Exploit (UPSynergy)\r\nDetermine the\r\nOS Type\r\nDetermined from the server’s session SetupAndX\r\nresponse (part of a session negotiation), where the\r\nunderlying target OS is specified.\r\nSame technique.\r\nDetermine the\r\nOS Bitness\r\nUses a leaked pool header structure that contains\r\nparameters from which the OS architecture can be\r\ninferred.\r\nUses the address of the  leaked\r\nCCB structure to infer the range\r\nin which it resides and  the\r\nunderlying architecture.\r\nGrooming\r\nTechnique (Heap\r\nShaping)\r\nUses 2 types of allocations with different sizes,\r\nnamed “bride” and “groom.” Another technique is\r\nused for OS versions prior to Windows 7.\r\nUses “bride” allocations only,\r\nwith a different allocation size.\r\nLeaked Object\r\nLeaks a kernel object named Transaction\r\n(corresponding to an SMB Transaction).\r\nLeaks a kernel object named\r\nCCB (Client Control Block).\r\nOOB Write\r\nVulnerability\r\nA result of a type confusion bug, as outlined above. Same vulnerability.\r\nWrite-What-Where primitive\r\nCan be achieved by overwriting the input buffer\r\npointer of a target Transaction structure, as outlined\r\nabove.\r\nSame technique.\r\nRead-What-Where primitive\r\nCan be achieved by overwriting the output buffer\r\npointer of a target Transaction structure, as outlined\r\nabove.\r\nAPT3 doesn’t use this primitive.\r\nRWE Cave Uses an RWE page in the srv.sys memory section. Uses HAL’s heap.\r\nFirst Shellcode\r\nExecution\r\nOverwrites an unimplemented SMB command\r\npointer in the SMB command handler table, and\r\nOverwrites a named pipe\r\nconnection handler function\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 9 of 25\n\nsends an SMB transaction for this command to\r\nexecute a handler (which is in fact shellcode).\r\nwhich executes after the\r\nconnection is closed.\r\nIn addition, we conducted a quantitative analysis of various actions performed during both exploits, as can be seen\r\nin the following table:\r\nParameter EternalRomance\r\nAPT3 Exploit\r\n(UPSynergy)\r\nInfo leak exploit usage 2 times 1 time\r\nUsage of a write-what-where primitive 24 times 3 times\r\nUsage of a read-what-where primitive 4 times Not used\r\nNumber of attempts to overwrite a Transaction structure in\r\ncase of failure on the first try\r\n2 attempts 0 attempts\r\nFrom this table, we can infer that the UPSynergy information leak significantly eases the exploitation process, as\r\nthe leaked CCB object described earlier contains almost a direct code execution primitive. In EternalRomance, we\r\ncould see the usage of a read-what-where primitive, mainly used for dereferencing child structs of a leaked\r\nTransaction struct. In the case of UPSynergy, that would be redundant.\r\nHaving said that, there is a slight chance of instability in the grooming implementation of UPSynergy, where a\r\nwrite to an unallocated page might lead to an unintended BSOD. This will not happen in EternalRomance (point\r\nfor the Equation group).\r\nComparison of APT3 and Equation Group Implants\r\nThe last action to take place following the exploitation is the set-up and invocation of an implant shellcode. The\r\npurpose is to serve as a basic backdoor, allowing the attacker to issue a further kernel mode payload and execute it\r\non the target machine. In the case of both APT3 and Equation group, an implant named DoublePulsar is used. This\r\nimplant was leaked by The Shadow Brokers in 2017.\r\nIn both cases, there is a very similar flow to the implant’s operation – a hook is set up for a particular SMB\r\nhandler function to handle invalid SMBs. This hook searches for one of 3 commands in a particular SMB field and\r\nexecutes a corresponding function for each one. One of the supported commands is responsible for accepting\r\nfurther shellcode and running it – the last stage payload. At this point, the attacker may issue an arbitrary piece of\r\ncode for execution in the kernel space.\r\nAs far as APT3’s implant is concerned, it seems likely f the DoublePulsar code was reused as is. The code is not\r\nexecuted directly, but has several layers of obfuscation. Essentially, the Equation group’s DoublePulsar code is\r\nwrapped with an APT3 position independent crypter \u0026 loader.\r\nIn the following sections, we take a look at the differences and supplements provided by APT3. As we will see,\r\nthe main logic flow was preserved in both cases. However, the differences show that APT3 did not want to fully\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 10 of 25\n\ndisclose the fact it was using an allegedly American implant.\r\n1st Stage – DoublePulsar Loader\r\nThe very first stage of the implant’s code is a custom loader written by APT3, which extracts an encrypted version\r\nof DoublePulsar code from incoming SMB packets, and decrypts and executes it. This is in fact a self-modifying\r\npiece of code, i.e. before it actually handles any of the aforementioned functionalities, it must decrypt subsequent\r\nparts of itself. The code is wrapped in 2 layers using simple crypters, so the first crypter decodes the second, and\r\nthe latter decodes the actual loader code.\r\nFigure 14: First and second phase of decoding the loader’s payload.\r\nAfter these phases are completed, the loader starts its operation which is broken down into the following steps:\r\n1. Dynamic function resolution.\r\n2. Determine the OS version.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 11 of 25\n\n3. Locate the SrvTreeConnectList in sys.\r\n4. Extract the encoded shellcode from a Transaction object list.\r\n5. Execute the shellcode.\r\nThe figure below summarizes this flow, showing the main code of this loader. We then present a detailed outline\r\nof each of these steps, and point out the major differences that set this code apart from that of the Equation group.\r\nFigure 15: The main flow of the 1st stage loader.\r\nStep 1: Dynamic function resolution\r\nAs this is essentially position independent code, we need to resolve some API functions dynamically, which are\r\nthen used during run time. First, we must locate the base address of the ntoskrnl.exe image. We do this by\r\nobtaining the KPCR structure from the FS register, and use offset 0x38 which points to KIDTENTRY *IDT (i.e.\r\nthe interrupt dispatch table). As we know the latter resides within ntoskrnl.exe and is aligned to the beginning of a\r\npage, so it is sufficient to walk back in page multiples until the start of the page is equivalent to the magic number\r\nof a PE.\r\nAfter that is done, it’s possible to parse the export table of ntoskrnl.exe to achieve several basic API function\r\naddresses. A common technique is to parse the export tables of a relevant loaded image where these functions\r\nreside (e.g. ntoskrnl.exe), hash the names of their exports, and compare them to hardcoded ones. The latter\r\nrepresent the names of the functions that require address resolution. In this case, we see that the hashing function\r\ndiffers from that of the Equation group, resulting in different name hashes.\r\nFunction Name APT3 Hash Equation Hash\r\nZwQuerySystemInformaiton 0x8754A7F7 0x0D2515B2E\r\nExAllocatePoolWithTag 0x37F154D9 –\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 12 of 25\n\nExAllocatePool – 0x0E3690194\r\nExFreePool 0x3F7747DE 0x0F0835485\r\nRtlGetVersion 0x0DDE5CDD –\r\nFigure 16: Different name hashing implementations and their resulting string hashes.\r\nWe see that not only   different hashing algorithms are used, but also different API functions. For instance, the\r\nEquation group uses a simple pool allocation via the ExAllocatePool API, while APT3 uses a tagged allocation\r\nand calls ExAllocatePoolWithTag. In the latter case, the used tag represents a work context structure.\r\nFigure 17: APT3 tagged allocation.\r\nStep 2: Determining the OS version\r\nNext, the loader invokes the RtlGetVersion function to obtain information about the underlying Windows version.\r\nIt then assigns a numeric value to a field in a particular struct maintained by the loader, which corresponds to the\r\nOS version. The value is in fact an offset into an undocumented SMB struct called CONNECTION, which will\r\nresult in a field that points to yet another undocumented struct called PAGED_CONNECTION. How  this struct is\r\nused will be evident in subsequent steps.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 13 of 25\n\nFigure 18: Determining the version of Windows, and choosing a corresponding offset value.\r\nStep 3: Locating sys and SrvTreeConnectList\r\nAt this point, the loader tries to find Srv.sys (the SMB driver’s image) and parse it. This is done to locate a global\r\nundocumented list named SrvTreeConnectList. Srv.sys is located using ZwQuerySystemInformation to obtain a list\r\nof loaded module information (where a base address of the loaded images is specified), while the struct is found\r\nby going through Srv.sys’ .data section and looking for several identifying numeric parameters.\r\nStep 4: Extracting encoded shellcode from a Transaction object list.\r\nAfter the list is found, it is used to go through several linked SMB structures to finally obtain a list of Transaction\r\nstructs. The latter allows us to access the data obtained from relevant SMB Trans packets which contains the\r\nsubsequent shellcode.\r\nThe chain of these structures can be seen in the figure below. The main takeaway is that all of these structures are\r\nundocumented – i.e. the developers of APT3 must have done quite a bit of reverse engineering on Srv.sys to infer\r\nthem (on more than one Windows version, as evident from the offset to PAGED_CONNECTION). This effort is\r\nvery similar to the one invested by the NSA to find the various Eternal exploits around the same time.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 14 of 25\n\nFigure 19: APT3’s code to ‘walk’ through various undocumented SMB strucures, suggesting that a considerable\r\nanalysis was performed and the group’s members have a good understanding of the SMB internals.\r\nStep 5: Executing the shellcode\r\nAfter the shellcode is obtained and decoded, it is finally executed. This leads to the next stage, which is yet\r\nanother piece of self-modifying PIC. However, in this case, most of the code that is unravelled after 2 layers of\r\ndecoding is a variant of the original DoublePulsar, as used by the Equation group.\r\n2nd Stage – DoublePulsar Installation \u0026 Hook\r\nIn this stage of the implant’s operation, yet another shellcode runs. As previously mentioned, this code is\r\nobfuscated with 2 layers of crypters, the same ones used to wrap the loader in the 1st stage. The code that is\r\nunpacked was mostly not written by APT3.\r\nThe first part of the resulting PIC seems to be custom-made, and invokes a system thread that works periodically\r\nto form paged allocations of various sizes. It can run in rounds indefinitely, creating 256 allocations for each round\r\nand counting the number that get an address within the range of 64 bytes from the point in which the first\r\nshellcode was written. Only if there are more than 64 ‘faulty’ allocations can this loop terminate. The purpose is\r\nnot fully clear, but could be an attempt to avoid paging out the shellcode buffers from the paged pool.\r\nThe other part of this internal payload installs DoublePulsar. This  is done by replacing a function pointer to point\r\nat a hook function instead of the original function named SrvTransactionNotImplemented. The replacement of this\r\npointer happens in a hard-coded table in the SMB driver (srv.sys) named SrvTransaction2DispatchTable.\r\nIn essence, both APT3 and the Equation group take similar steps to achieve this goal. These are outlined in the\r\nfigure below, and are more thoroughly explained here and here.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 15 of 25\n\nFigure 20: The general steps taken to install DoublePulsar’s hook, in both implementations of the shellcode. \r\nYou can see the similarity in the call flow graph comparison of these hook functions:\r\nFigure 21: CFG comparison of the DoublePulsar hook functions.\r\nThis particular hook function anticipates an initial command named “ping” where a XOR key is obtained from the\r\nattacker. This key can then be used to decode the payload of subsequent SMBs carrying additional shellcode. The\r\nlatter is executed as part of another command called “exec”.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 16 of 25\n\nFigure 22: Commands supported by the 2nd stage hook backdoor.\r\nThere is an addition to the code that was not observed in other variants of DoublePulsar. This addition is a\r\ncommon snippet used to disable the WP bit flag of the CR0 register, which allows the kernel to write into read\r\nonly pages. It is not clear if this serves any purpose in the implant’s operation, but it is reasonable to assume that it\r\nwas bundled to a version of DoublePulsar that was captured by APT3 and was simply left as a code residue.\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 17 of 25\n\nFigure 23: Code snippet from DoublePulsar, used to clear the WP flag in CR0.\r\n3rd Stage – APC Injector\r\nThe last stage of the implant is a piece of code that performs APC injection of a hardcoded routine to the\r\n“services.exe” process in the user space. In turn, this routine can write a given payload to a new file and execute it,\r\nor run a shell command. In both cases, the API used for the execution is WinExec.\r\nIt’s worth noting that while an arbitrary command can be issued by the user, there are several hardcoded\r\ncommands that the shellcode runs through the invoked APC in the user space. One of these commands adds a new\r\nuser as local admin with a hardcoded name and password. In the sample analyzed for this publication, this\r\nusername is cessupport and the password is 1qaz#EDC.\r\nFigure 24: Hardcoded shell command to add a new admin user to the system.\r\nThe implementation of this part doesn’t resemble that of the Equation group (compared to their equivalent APC\r\ninjector). It’s also different from the previous stages of APT3’s implant. For example, function resolution does not\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 18 of 25\n\nuse string hashes anymore, but rather makes comparisons to strings stored in the stack.  The allocations are no\r\nlonger tagged and the overall choice of API functions for similar actions looks different. This may mean that there\r\nwas another entity within the group that was involved in the development of this part, but not of previous ones.\r\nConclusion\r\nIn our research, we analyzed and compared the exploit development efforts done by 2 major actors in the APT\r\nlandscape – the Equation group and APT3. While the former is known for its advanced and almost unparalleled\r\ncapabilities in the field of vulnerability research, it is interesting to observe how other groups focus on similar\r\nresearch objectives, with a considerable degree of success.\r\nIt’s not always clear how threat actors achieve their exploitation tools, and it’s commonly assumed that actors can\r\nconduct their own research and development or get it from a third party. In this case we have evidence to show\r\nthat a third (but less common) scenario took place – one where attack artifacts of a rival (i.e. Equation group) were\r\nused as the basis and inspiration for establishing in-house offensive capabilities by APT3.\r\nAlthough we can’t prove this beyond any doubt, we brought many facts and analysis findings to back up our\r\nspeculations.  We will continue our efforts to find the answers to these as well as any future questions that arise.\r\nCheck Point protects against the exploits issued by the Bemstour tool with the IPS protection ‘Microsoft SMB\r\nClient Transaction Memory Corruption (MS10-020)’.\r\nWe would like to thank Eyal Itkin for assisting in parts of the analysis during this research.\r\nIOCs\r\nMD5:\r\nF595228976CC89FFAC02D831E774CFA6\r\nSHA1:\r\n80143E32F887B2583B777DAEC5982FB5C2886FB3\r\nSHA256:\r\n0B28433A2B7993DA65E95A45C2ADF7BC37EDBD2A8DB717B85666D6C88140698A\r\nYara Rules:\r\nrule apt3_bemstour_strings\r\n{\r\nmeta:\r\ndescription = \"Detects strings used by the Bemstour exploitation tool\"\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 19 of 25\n\nauthor = \"Mark Lechtik\"\r\ncompany = \"Check Point Software Technologies LTD.\"\r\ndate = \"2019-06-25\"\r\nsha256 = \"0b28433a2b7993da65e95a45c2adf7bc37edbd2a8db717b85666d6c88140698a\"\r\nstrings:\r\n$dbg_print_1 = \"leaked address is 0x%llx\" ascii wide\r\n$dbg_print_2 = \"========== %s ==========\" ascii wide\r\n$dbg_print_3 = \"detailVersion:%d\" ascii wide\r\n$dbg_print_4 = \"create pipe twice failed\" ascii wide\r\n$dbg_print_5 = \"WSAStartup function failed with error: %d\" ascii wide\r\n$dbg_print_6 = \"can't open input file.\" ascii wide\r\n$dbg_print_7 = \"Allocate Buffer Failed.\" ascii wide\r\n$dbg_print_8 = \"Connect to target failed.\" ascii wide\r\n$dbg_print_9 = \"connect successful.\" ascii wide\r\n$dbg_print_10 = \"not supported Platform\" ascii wide\r\n$dbg_print_11 = \"Wait several seconds.\" ascii wide\r\n$dbg_print_12 = \"not set where to write ListEntry .\" ascii wide\r\n$dbg_print_13 = \"backdoor not installed.\" ascii wide\r\n$dbg_print_14 = \"REConnect to target failed.\" ascii wide\r\n$dbg_print_15 = \"Construct TreeConnectAndX Request Failed.\" ascii wide\r\n$dbg_print_16 = \"Construct NTCreateAndXRequest Failed.\" ascii wide\r\n$dbg_print_17 = \"Construct Trans2 Failed.\" ascii wide\r\n$dbg_print_18 = \"Construct ConsWXR Failed.\" ascii wide\r\n$dbg_print_19 = \"Construct ConsTransSecondary Failed.\" ascii wide\r\n$dbg_print_20 = \"if you don't want to input password , use server2003 version..\" ascii wide\r\n$cmdline_1 = \"Command format %s TargetIp domainname username password 2\" ascii wide\r\n$cmdline_2 = \"Command format %s TargetIp domainname username password 1\" ascii wide\r\n$cmdline_3 = \"cmd.exe /c net user test test /add \u0026\u0026 cmd.exe /c net localgroup administrators test /ad\r\n$cmdline_4 = \"hello.exe \\\"C:\\\\WINDOWS\\\\DEBUG\\\\test.exe\\\"\" ascii wide\r\n$cmdline_5 = \"parameter not right\" ascii wide\r\n$smb_param_1 = \"browser\" ascii wide\r\n$smb_param_2 = \"spoolss\" ascii wide\r\n$smb_param_3 = \"srvsvc\" ascii wide\r\n$smb_param_4 = \"\\\\PIPE\\\\LANMAN\" ascii wide\r\n$smb_param_5 = \"Werttys for Workgroups 3.1a\" ascii wide\r\n$smb_param_6 = \"PC NETWORK PROGRAM 1.0\" ascii wide\r\n$smb_param_7 = \"LANMAN1.0\" ascii wide\r\n$smb_param_8 = \"LM1.2X002\" ascii wide\r\n$smb_param_9 = \"LANMAN2.1\" ascii wide\r\n$smb_param_10 = \"NT LM 0.12\" ascii wide\r\n$smb_param_12 = \"WORKGROUP\" ascii wide\r\n$smb_param_13 = \"Windows Server 2003 3790 Service Pack 2\" ascii wide\r\n$smb_param_14 = \"Windows Server 2003 5.2\" ascii wide\r\n$smb_param_15 = \"Windows 2002 Service Pack 2 2600\" ascii wide\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 20 of 25\n\n$smb_param_16 = \"Windows 2002 5.1\" ascii wide\r\n$smb_param_17 = \"PC NETWORK PROGRAM 1.0\" ascii wide\r\n$smb_param_18 = \"Windows 2002 5.1\" ascii wide\r\n$smb_param_19 = \"Windows for Workgroups 3.1a\" ascii wide\r\n$unique_str_1 = \"WIN-NGJ7GKNROVS\"\r\n$unique_str_2 = \"XD-A31C2E0087B2\"\r\ncondition:\r\n uint16(0) == 0x5a4d and (5 of ($dbg_print*) or 2 of ($cmdline*) or 1 of ($unique_str*)) and 3 of\r\n}\r\nrule apt3_bemstour_implant_byte_patch\r\n{\r\nmeta:\r\ndescription = \"Detects an implant used by Bemstour exploitation tool (APT3)\"\r\nauthor = \"Mark Lechtik\"\r\ncompany = \"Check Point Software Technologies LTD.\"\r\ndate = \"2019-06-25\"\r\nsha256 = \"0b28433a2b7993da65e95a45c2adf7bc37edbd2a8db717b85666d6c88140698a\"\r\n/*\r\n0x41b7e1L C745B8558BEC83 mov dword ptr [ebp - 0x48], 0x83ec8b55\r\n0x41b7e8L C745BCEC745356 mov dword ptr [ebp - 0x44], 0x565374ec\r\n0x41b7efL C745C08B750833 mov dword ptr [ebp - 0x40], 0x3308758b\r\n0x41b7f6L C745C4C957C745 mov dword ptr [ebp - 0x3c], 0x45c757c9\r\n0x41b7fdL C745C88C4C6F61 mov dword ptr [ebp - 0x38], 0x616f4c8c\r\n*/\r\nstrings:\r\n$chunk_1 = {\r\nC7 45 ?? 55 8B EC 83\r\nC7 45 ?? EC 74 53 56\r\nC7 45 ?? 8B 75 08 33\r\nC7 45 ?? C9 57 C7 45\r\nC7 45 ?? 8C 4C 6F 61\r\n}\r\ncondition:\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 21 of 25\n\nany of them\r\n}\r\nrule apt3_bemstour_implant_command_stack_variable\r\n{\r\nmeta:\r\ndescription = \"Detecs an implant used by Bemstour exploitation tool (APT3)\"\r\nauthor = \"Mark Lechtik\"\r\ncompany = \"Check Point Software Technologies LTD.\"\r\ndate = \"2019-06-25\"\r\nsha256 = \"0b28433a2b7993da65e95a45c2adf7bc37edbd2a8db717b85666d6c88140698a\"\r\nstrings:\r\n/*\r\n0x41ba18L C78534FFFFFF636D642E mov dword ptr [ebp - 0xcc], 0x2e646d63\r\n0x41ba22L C78538FFFFFF65786520 mov dword ptr [ebp - 0xc8], 0x20657865\r\n0x41ba2cL C7853CFFFFFF2F632063 mov dword ptr [ebp - 0xc4], 0x6320632f\r\n0x41ba36L C78540FFFFFF6F707920 mov dword ptr [ebp - 0xc0], 0x2079706f\r\n0x41ba40L C78544FFFFFF2577696E mov dword ptr [ebp - 0xbc], 0x6e697725\r\n0x41ba4aL C78548FFFFFF64697225 mov dword ptr [ebp - 0xb8], 0x25726964\r\n0x41ba54L C7854CFFFFFF5C737973 mov dword ptr [ebp - 0xb4], 0x7379735c\r\n0x41ba5eL C78550FFFFFF74656D33 mov dword ptr [ebp - 0xb0], 0x336d6574\r\n0x41ba68L C78554FFFFFF325C636D mov dword ptr [ebp - 0xac], 0x6d635c32\r\n0x41ba72L C78558FFFFFF642E6578 mov dword ptr [ebp - 0xa8], 0x78652e64\r\n0x41ba7cL C7855CFFFFFF65202577 mov dword ptr [ebp - 0xa4], 0x77252065\r\n0x41ba86L C78560FFFFFF696E6469 mov dword ptr [ebp - 0xa0], 0x69646e69\r\n0x41ba90L C78564FFFFFF72255C73 mov dword ptr [ebp - 0x9c], 0x735c2572\r\n0x41ba9aL C78568FFFFFF79737465 mov dword ptr [ebp - 0x98], 0x65747379\r\n0x41baa4L C7856CFFFFFF6D33325C mov dword ptr [ebp - 0x94], 0x5c32336d\r\n0x41baaeL C78570FFFFFF73657468 mov dword ptr [ebp - 0x90], 0x68746573\r\n0x41bab8L C78574FFFFFF632E6578 mov dword ptr [ebp - 0x8c], 0x78652e63\r\n0x41bac2L C78578FFFFFF65202F79 mov dword ptr [ebp - 0x88], 0x792f2065\r\n0x41baccL 83A57CFFFFFF00 and dword ptr [ebp - 0x84], 0\r\n*/\r\n$chunk_1 = {\r\nC7 85 ?? ?? ?? ?? 63 6D 64 2E\r\nC7 85 ?? ?? ?? ?? 65 78 65 20\r\nC7 85 ?? ?? ?? ?? 2F 63 20 63\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 22 of 25\n\nC7 85 ?? ?? ?? ?? 6F 70 79 20\r\nC7 85 ?? ?? ?? ?? 25 77 69 6E\r\nC7 85 ?? ?? ?? ?? 64 69 72 25\r\nC7 85 ?? ?? ?? ?? 5C 73 79 73\r\nC7 85 ?? ?? ?? ?? 74 65 6D 33\r\nC7 85 ?? ?? ?? ?? 32 5C 63 6D\r\nC7 85 ?? ?? ?? ?? 64 2E 65 78\r\nC7 85 ?? ?? ?? ?? 65 20 25 77\r\nC7 85 ?? ?? ?? ?? 69 6E 64 69\r\nC7 85 ?? ?? ?? ?? 72 25 5C 73\r\nC7 85 ?? ?? ?? ?? 79 73 74 65\r\nC7 85 ?? ?? ?? ?? 6D 33 32 5C\r\nC7 85 ?? ?? ?? ?? 73 65 74 68\r\nC7 85 ?? ?? ?? ?? 63 2E 65 78\r\nC7 85 ?? ?? ?? ?? 65 20 2F 79\r\n83 A5 ?? ?? ?? ?? 00\r\n}\r\n/*\r\n0x41baeeL C785D8FEFFFF636D6420 mov dword ptr [ebp - 0x128], 0x20646d63\r\n0x41baf8L C785DCFEFFFF2F632022 mov dword ptr [ebp - 0x124], 0x2220632f\r\n0x41bb02L C785E0FEFFFF6E657420 mov dword ptr [ebp - 0x120], 0x2074656e\r\n0x41bb0cL C785E4FEFFFF75736572 mov dword ptr [ebp - 0x11c], 0x72657375\r\n0x41bb16L C785E8FEFFFF20636573 mov dword ptr [ebp - 0x118], 0x73656320\r\n0x41bb20L C785ECFEFFFF73757070 mov dword ptr [ebp - 0x114], 0x70707573\r\n0x41bb2aL C785F0FEFFFF6F727420 mov dword ptr [ebp - 0x110], 0x2074726f\r\n0x41bb34L C785F4FEFFFF3171617A mov dword ptr [ebp - 0x10c], 0x7a617131\r\n0x41bb3eL C785F8FEFFFF23454443 mov dword ptr [ebp - 0x108], 0x43444523\r\n0x41bb48L C785FCFEFFFF202F6164 mov dword ptr [ebp - 0x104], 0x64612f20\r\n0x41bb52L C78500FFFFFF64202626 mov dword ptr [ebp - 0x100], 0x26262064\r\n0x41bb5cL C78504FFFFFF206E6574 mov dword ptr [ebp - 0xfc], 0x74656e20\r\n0x41bb66L C78508FFFFFF206C6F63 mov dword ptr [ebp - 0xf8], 0x636f6c20\r\n0x41bb70L C7850CFFFFFF616C6772 mov dword ptr [ebp - 0xf4], 0x72676c61\r\n0x41bb7aL C78510FFFFFF6F757020 mov dword ptr [ebp - 0xf0], 0x2070756f\r\n0x41bb84L C78514FFFFFF61646D69 mov dword ptr [ebp - 0xec], 0x696d6461\r\n0x41bb8eL C78518FFFFFF6E697374 mov dword ptr [ebp - 0xe8], 0x7473696e\r\n0x41bb98L C7851CFFFFFF7261746F mov dword ptr [ebp - 0xe4], 0x6f746172\r\n0x41bba2L C78520FFFFFF72732063 mov dword ptr [ebp - 0xe0], 0x63207372\r\n0x41bbacL C78524FFFFFF65737375 mov dword ptr [ebp - 0xdc], 0x75737365\r\n0x41bbb6L C78528FFFFFF70706F72 mov dword ptr [ebp - 0xd8], 0x726f7070\r\n0x41bbc0L C7852CFFFFFF74202F61 mov dword ptr [ebp - 0xd4], 0x612f2074\r\n0x41bbcaL C78530FFFFFF64642200 mov dword ptr [ebp - 0xd0], 0x226464\r\n0x41bbd4L 6A5C push 0x5c\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 23 of 25\n\n*/\r\n$chunk_2 = {\r\nC7 85 ?? ?? ?? ?? 63 6D 64 20\r\nC7 85 ?? ?? ?? ?? 2F 63 20 22\r\nC7 85 ?? ?? ?? ?? 6E 65 74 20\r\nC7 85 ?? ?? ?? ?? 75 73 65 72\r\nC7 85 ?? ?? ?? ?? 20 63 65 73\r\nC7 85 ?? ?? ?? ?? 73 75 70 70\r\nC7 85 ?? ?? ?? ?? 6F 72 74 20\r\nC7 85 ?? ?? ?? ?? 31 71 61 7A\r\nC7 85 ?? ?? ?? ?? 23 45 44 43\r\nC7 85 ?? ?? ?? ?? 20 2F 61 64\r\nC7 85 ?? ?? ?? ?? 64 20 26 26\r\nC7 85 ?? ?? ?? ?? 20 6E 65 74\r\nC7 85 ?? ?? ?? ?? 20 6C 6F 63\r\nC7 85 ?? ?? ?? ?? 61 6C 67 72\r\nC7 85 ?? ?? ?? ?? 6F 75 70 20\r\nC7 85 ?? ?? ?? ?? 61 64 6D 69\r\nC7 85 ?? ?? ?? ?? 6E 69 73 74\r\nC7 85 ?? ?? ?? ?? 72 61 74 6F\r\nC7 85 ?? ?? ?? ?? 72 73 20 63\r\nC7 85 ?? ?? ?? ?? 65 73 73 75\r\nC7 85 ?? ?? ?? ?? 70 70 6F 72\r\nC7 85 ?? ?? ?? ?? 74 20 2F 61\r\nC7 85 ?? ?? ?? ?? 64 64 22 00\r\n6A 5C\r\n}\r\n/*\r\n0x41be22L C745D057696E45 mov dword ptr [ebp - 0x30], 0x456e6957\r\n0x41be29L C745D478656300 mov dword ptr [ebp - 0x2c], 0x636578\r\n0x41be30L C7459C47657450 mov dword ptr [ebp - 0x64], 0x50746547\r\n0x41be37L C745A0726F6341 mov dword ptr [ebp - 0x60], 0x41636f72\r\n0x41be3eL C745A464647265 mov dword ptr [ebp - 0x5c], 0x65726464\r\n0x41be45L C745A873730000 mov dword ptr [ebp - 0x58], 0x7373\r\n0x41be4cL C745C443726561 mov dword ptr [ebp - 0x3c], 0x61657243\r\n0x41be53L C745C874654669 mov dword ptr [ebp - 0x38], 0x69466574\r\n0x41be5aL C745CC6C654100 mov dword ptr [ebp - 0x34], 0x41656c\r\n0x41be61L C745B857726974 mov dword ptr [ebp - 0x48], 0x74697257\r\n0x41be68L C745BC6546696C mov dword ptr [ebp - 0x44], 0x6c694665\r\n0x41be6fL C745C065000000 mov dword ptr [ebp - 0x40], 0x65\r\n0x41be76L C745AC436C6F73 mov dword ptr [ebp - 0x54], 0x736f6c43\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 24 of 25\n\n0x41be7dL C745B06548616E\r\nmov dword ptr [ebp - 0x50], 0x6e614865\r\n0x41be84L C745B4646C6500mov dword ptr [ebp - 0x4c], 0x656c64\r\n0x41be8bL 894DE8 mov dword ptr [ebp - 0x18], ecx\r\n*/\r\n$chunk_3 = {\r\nC7 45 ?? 57 69 6E 45\r\nC7 45 ?? 78 65 63 00\r\nC7 45 ?? 47 65 74 50\r\nC7 45 ?? 72 6F 63 41\r\nC7 45 ?? 64 64 72 65\r\nC7 45 ?? 73 73 00 00\r\nC7 45 ?? 43 72 65 61\r\nC7 45 ?? 74 65 46 69\r\nC7 45 ?? 6C 65 41 00\r\nC7 45 ?? 57 72 69 74\r\nC7 45 ?? 65 46 69 6C\r\nC7 45 ?? 65 00 00 00\r\nC7 45 ?? 43 6C 6F 73\r\nC7 45 ?? 65 48 61 6E\r\nC7 45 ?? 64 6C 65 00\r\n89 4D ??\r\n}\r\ncondition:\r\n any of them\r\n}\r\nSource: https://research.checkpoint.com/upsynergy/\r\nhttps://research.checkpoint.com/upsynergy/\r\nPage 25 of 25\n\n$smb_param_10 $smb_param_12 = \"NT LM 0.12\" = \"WORKGROUP\" ascii wide ascii wide  \n$smb_param_13 = \"Windows Server 2003 3790 Service Pack 2\" ascii wide\n$smb_param_14 = \"Windows Server 2003 5.2\" ascii wide \n$smb_param_15 = \"Windows 2002 Service Pack 2 2600\" ascii wide\n   Page 20 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/upsynergy/"
	],
	"report_names": [
		"upsynergy"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-18T02:00:04.659756Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "d4f7cf97-9c98-409c-8b95-b80d14c576a5",
			"created_at": "2022-10-25T16:07:24.561104Z",
			"updated_at": "2026-04-18T02:00:05.399493Z",
			"deleted_at": null,
			"main_name": "Shadow Brokers",
			"aliases": [],
			"source_name": "ETDA:Shadow Brokers",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "171b85f2-8f6f-46c0-92e0-c591f61ea167",
			"created_at": "2023-01-06T13:46:38.830188Z",
			"updated_at": "2026-04-18T02:00:03.404718Z",
			"deleted_at": null,
			"main_name": "The Shadow Brokers",
			"aliases": [
				"Shadow Brokers",
				"ShadowBrokers",
				"The ShadowBrokers",
				"TSB"
			],
			"source_name": "MISPGALAXY:The Shadow Brokers",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "13354d3f-3f40-44ec-b42a-3cda18809005",
			"created_at": "2022-10-25T15:50:23.275272Z",
			"updated_at": "2026-04-18T02:00:04.813846Z",
			"deleted_at": null,
			"main_name": "APT3",
			"aliases": [
				"APT3",
				"Gothic Panda",
				"Pirpi",
				"UPS Team",
				"Buckeye",
				"Threat Group-0110",
				"TG-0110"
			],
			"source_name": "MITRE:APT3",
			"tools": [
				"OSInfo",
				"schtasks",
				"PlugX",
				"LaZagne",
				"SHOTPUT",
				"RemoteCMD"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "761d1fb2-60e3-46f0-9f1c-c8a9715967d4",
			"created_at": "2023-01-06T13:46:38.269054Z",
			"updated_at": "2026-04-18T02:00:03.175324Z",
			"deleted_at": null,
			"main_name": "APT3",
			"aliases": [
				"GOTHIC PANDA",
				"Group 6",
				"Red Sylvan",
				"Brocade Typhoon",
				"TG-0110",
				"Buckeye",
				"Boyusec",
				"BORON",
				"BRONZE MAYFAIR"
			],
			"source_name": "MISPGALAXY:APT3",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "08623296-52be-4977-8622-50efda44e9cc",
			"created_at": "2023-01-06T13:46:38.549387Z",
			"updated_at": "2026-04-18T02:00:03.300757Z",
			"deleted_at": null,
			"main_name": "Equation Group",
			"aliases": [
				"Tilded Team",
				"EQGRP",
				"G0020"
			],
			"source_name": "MISPGALAXY:Equation Group",
			"tools": [
				"DoubleFantasy",
				"TripleFantasy",
				"GrayFish",
				"EquationLaser",
				"EquationDrug"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2d9fbbd7-e4c3-40e5-b751-27af27c8610b",
			"created_at": "2024-05-01T02:03:08.144214Z",
			"updated_at": "2026-04-18T02:00:04.652818Z",
			"deleted_at": null,
			"main_name": "PLATINUM COLONY",
			"aliases": [
				"Equation Group "
			],
			"source_name": "Secureworks:PLATINUM COLONY",
			"tools": [
				"DoubleFantasy",
				"EquationDrug",
				"EquationLaser",
				"Fanny",
				"GrayFish",
				"TripleFantasy"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "e0fed6e6-a593-4041-80ef-694261825937",
			"created_at": "2022-10-25T16:07:23.593572Z",
			"updated_at": "2026-04-18T02:00:05.033272Z",
			"deleted_at": null,
			"main_name": "Equation Group",
			"aliases": [
				"APT-C-40",
				"G0020",
				"Platinum Colony",
				"Tilded Team"
			],
			"source_name": "ETDA:Equation Group",
			"tools": [
				"Bvp47",
				"DEMENTIAWHEEL",
				"DOUBLEFANTASY",
				"DanderSpritz",
				"DarkPulsar",
				"DoubleFantasy",
				"DoubleFeature",
				"DoublePulsar",
				"Duqu",
				"EQUATIONDRUG",
				"EQUATIONLASER",
				"EQUESTRE",
				"Flamer",
				"GRAYFISH",
				"GROK",
				"OddJob",
				"Plexor",
				"Prax",
				"Regin",
				"Skywiper",
				"TRIPLEFANTASY",
				"Tilded",
				"UNITEDRAKE",
				"WarriorPride",
				"sKyWIper"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "cf826655-5fcb-4331-bdc5-5ef267db9d3c",
			"created_at": "2025-08-07T02:03:24.631402Z",
			"updated_at": "2026-04-18T02:00:04.568151Z",
			"deleted_at": null,
			"main_name": "BRONZE MAYFAIR",
			"aliases": [
				"APT3 ",
				"Gothic Panda ",
				"Pirpi",
				"TG-0110 ",
				"UPSTeam"
			],
			"source_name": "Secureworks:BRONZE MAYFAIR",
			"tools": [
				"Cookiecutter",
				"HUC Proxy Malware (Htran)",
				"Pirpi",
				"PlugX",
				"SplitVPN",
				"UPS",
				"ctt",
				"ctx"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "06f622cb-3a78-49cf-9a4c-a6007a69325f",
			"created_at": "2022-10-25T16:07:23.315239Z",
			"updated_at": "2026-04-18T02:00:04.857108Z",
			"deleted_at": null,
			"main_name": "APT 3",
			"aliases": [
				"APT 3",
				"Boron",
				"Brocade Typhoon",
				"Bronze Mayfair",
				"Buckeye",
				"G0022",
				"Gothic Panda",
				"Group 6",
				"Operation Clandestine Fox",
				"Operation Clandestine Fox, Part Deux",
				"Operation Clandestine Wolf",
				"Operation Double Tap",
				"Red Sylvan",
				"TG-0110",
				"UPS Team"
			],
			"source_name": "ETDA:APT 3",
			"tools": [
				"APT3 Keylogger",
				"Agent.dhwf",
				"BKDR_HUPIGON",
				"Backdoor.APT.CookieCutter",
				"Badey",
				"Bemstour",
				"CookieCutter",
				"Destroy RAT",
				"DestroyRAT",
				"DoublePulsar",
				"EXL",
				"EternalBlue",
				"HTran",
				"HUC Packet Transmit Tool",
				"Hupigon",
				"Hupigon RAT",
				"Kaba",
				"Korplug",
				"LaZagne",
				"MFC Huner",
				"OSInfo",
				"Pirpi",
				"PlugX",
				"RedDelta",
				"RemoteCMD",
				"SHOTPUT",
				"Sogu",
				"TIGERPLUG",
				"TTCalc",
				"TVT",
				"Thoper",
				"Xamtrav",
				"remotecmd",
				"shareip",
				"w32times"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1776392427,
	"ts_updated_at": 1776478887,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e94c0d98494a122e3438171f0e3a2aca87b3d1e2.pdf",
		"text": "https://archive.orkl.eu/e94c0d98494a122e3438171f0e3a2aca87b3d1e2.txt",
		"img": "https://archive.orkl.eu/e94c0d98494a122e3438171f0e3a2aca87b3d1e2.jpg"
	}
}