🔒
There are new articles available, click to refresh the page.
Before yesterdayThreat Research

Havex, It’s Down With OPC

17 July 2014 at 14:00

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1 [3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

 

 

havex1

Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno [1] as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers [2] (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.

havex2

Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).

havex3

Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer [1], which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.

havex4

Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll" file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.

Analysis

The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function.  The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions.  Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking.  The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:

 

 

 

Screen Shot 2014-07-17 at 12.31.56 PM

 

 

Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Screen Shot 2014-07-17 at 12.33.22 PM

            Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls.  The encryption process uses an RSA public key obtained from the PE resource TYU.  The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”.  A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Screen Shot 2014-07-17 at 12.27.24 PM

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.

 

 

 

 

 

 

 

 

 

 

 

 

 

00000000  32 39 0a 66 00 66 00 30  00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030  00 30 00 66 00 66 00 30  00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040  0a 31 32 38 0a 96 26 cc  34 93 a5 4a 09 09 17 d3 .128..&.4..J....00000050  e0 bb 15 90 e8 5d cb 01  c0 33 c1 a4 41 72 5f a5 .....]...3..Ar_.00000060  13 43 69 62 cf a3 80 e3  6f ce 2f 95 d1 38 0f f2 .Cib....o./..8..00000070  56 b1 f9 5e 1d e1 43 92  61 f8 60 1d 06 04 ad f9 V..^..C.a.`.....00000080  66 98 1f eb e9 4c d3 cb  ee 4a 39 75 31 54 b8 02 f....L...J9u1T..00000090  b5 b6 4a 3c e3 77 26 6d  93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0  08 6a 22 89 b7 d3 72 d4  1f 8d b6 80 2b d2 99 5d .j"...r.....+..]000000B0  61 87 c1 0c 47 27 6a 61  fc c5 ee 41 a5 ae 89 c3 a...G'ja...A....000000C0  9e 00 54 b9 46 b8 88 72  94 a3 95 c8 8e 5d fe 23 ..T.F..r.....].#000000D0  2d fb 48 85 d5 31 c7 65  f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k

 

--Truncated--Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72  94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file

Execution

When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:

 

 

Screen Shot 2014-07-17 at 12.41.27 PM

 

 

Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:

 

 

Screen Shot 2014-07-17 at 12.43.48 PM

 

 

Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.

Conclusion

Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant.  We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.

Acknowledgements

We would like to thank Josh Homan for his help and support.

Related MD5s

ba8da708b8784afd36c44bb5f1f436bc

6bfc42f7cb1364ef0bfd749776ac6d38

4102f370aaf46629575daffbd5a0b3c9

References

Havex, It’s Down With OPC

17 July 2014 at 14:00

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1 [3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

 

 

havex1

Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno [1] as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers [2] (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.

havex2

Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).

havex3

Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer [1], which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.

havex4

Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll" file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.

Analysis

The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function.  The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions.  Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking.  The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:

 

 

 

Screen Shot 2014-07-17 at 12.31.56 PM

 

 

Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Screen Shot 2014-07-17 at 12.33.22 PM

            Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls.  The encryption process uses an RSA public key obtained from the PE resource TYU.  The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”.  A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Screen Shot 2014-07-17 at 12.27.24 PM

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.

 

 

 

 

 

 

 

 

 

 

 

 

 

00000000  32 39 0a 66 00 66 00 30  00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030  00 30 00 66 00 66 00 30  00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040  0a 31 32 38 0a 96 26 cc  34 93 a5 4a 09 09 17 d3 .128..&.4..J....00000050  e0 bb 15 90 e8 5d cb 01  c0 33 c1 a4 41 72 5f a5 .....]...3..Ar_.00000060  13 43 69 62 cf a3 80 e3  6f ce 2f 95 d1 38 0f f2 .Cib....o./..8..00000070  56 b1 f9 5e 1d e1 43 92  61 f8 60 1d 06 04 ad f9 V..^..C.a.`.....00000080  66 98 1f eb e9 4c d3 cb  ee 4a 39 75 31 54 b8 02 f....L...J9u1T..00000090  b5 b6 4a 3c e3 77 26 6d  93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0  08 6a 22 89 b7 d3 72 d4  1f 8d b6 80 2b d2 99 5d .j"...r.....+..]000000B0  61 87 c1 0c 47 27 6a 61  fc c5 ee 41 a5 ae 89 c3 a...G'ja...A....000000C0  9e 00 54 b9 46 b8 88 72  94 a3 95 c8 8e 5d fe 23 ..T.F..r.....].#000000D0  2d fb 48 85 d5 31 c7 65  f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k

 

--Truncated--Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72  94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file

Execution

When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:

 

 

Screen Shot 2014-07-17 at 12.41.27 PM

 

 

Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:

 

 

Screen Shot 2014-07-17 at 12.43.48 PM

 

 

Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.

Conclusion

Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant.  We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.

Acknowledgements

We would like to thank Josh Homan for his help and support.

Related MD5s

ba8da708b8784afd36c44bb5f1f436bc

6bfc42f7cb1364ef0bfd749776ac6d38

4102f370aaf46629575daffbd5a0b3c9

References

Connecting the Dots: Syrian Malware Team Uses BlackWorm for Attacks

29 August 2014 at 08:00

The Syrian Electronic Army has made news for its recent attacks on major communications websites, Forbes, and an alleged attack on CENTCOM. While these attacks garnered public attention, the activities of another group - The Syrian Malware Team - have gone largely unnoticed. The group’s activities prompted us to take a closer look. We discovered this group using a .NET based RAT called BlackWorm to infiltrate their targets.

The Syrian Malware Team is largely pro-Syrian government, as seen in one of their banners featuring Syrian President Bashar al-Assad. Based on the sentiments publicly expressed by this group it is likely that they are either directly or indirectly involved with the Syrian government. Further certain members of the Syrian Malware Team have ties to the Syrian Electronic army (SEA) known to be linked to the Syrian government. This indicates that the Syrian Malware Team may also be possibly an offshoot or part of the SEA.

syria1

Banner used by the Syrian Malware Team

BlackWorm Authorship

We found at least two distinct versions of the BlackWorm tool, including an original/private version (v0.3.0) and the Dark Edition (v2.1). The original BlackWorm builder was co-authored by Naser Al Mutairi from Kuwait, better known by his online moniker 'njq8'. He is also known to have coded njw0rm, njRAT/LV, and earlier versions of H-worm/Houdini. We found his code being used in a slew of other RATs such as Fallaga and Spygate. BlackWorm v0.3.0 was also co-authored by another actor, Black Mafia.

syria2

About section within the original version of BlackWorm builder

Within the underground development forums, it’s common for threat actors to collaborate on toolsets. Some write the base tools that other attackers can use; others modify and enhance existing tools.

The BlackWorm builder v2.1 is a prime example of actors modifying and enhancing current RATs. After njq8 and Black Mafia created the original builder, another author, Black.Hacker, enhanced its feature set.

syria3

About section within BlackWorm Dark Edition builder

syria4

Black.Hacker's banner on social media

syria5

As an interesting side note, 'njq8' took down his blog in recent months and announced a cease in all malware development activity on his Twitter and Facebook account, urging others to stop as well. This is likely a direct result of the lawsuit filed against him by Microsoft.

BlackWorm RAT Features

The builder for BlackWorm v0.3.0 is fairly simple and allows for very quick payload, but doesn’t allow any configuration other than the IP address for command and control (C2).

syria6

Building binary through BlackWorm v0.3.0

syria7

BlackWorm v0.3.0 controller

BlackWorm v0.3.0 supports the following commands between the controller and the implant:

ping Checks if victim is online
closeserver Exits the implant
restartserver Restarts the implant
sendfile Transfer and run file from server
download Download and run file from URL
ddos Ping flood target
msgbox Message interaction with victim
down Kill critical windows processes
blocker Block specified website by pointing resolution to 127.0.0.1
logoff Logout out of windows
restart Restart system
shutdown Shutdown system
more Disable task manager, registry tools, system restore. Also blocks keyboard and mouse input
hror Displays a startling flash video

In addition to the features supported by the command structure, the payload can:

  • Seek and kill no-ip processes DUC30 and DUC20
  • Disable Task Manager to kill process dialog
  • Copy itself to USB drives and create autorun entries
  • Copy itself to common peer-to-peer (P2P) share locations
  • Collect system information such as OS, username, hostname, presence of camera, active window name, etc., to display in the controller
  • Kill the following analysis processes (if found):
    • procexp
    • SbieCtrl
    • SpyTheSpy
    • SpeedGear
    • Wireshark
    • MBAM
    • ApateDNS
    • IPBlocker
    • cPorts
    • ProcessHacker
    • AntiLogger

The Syrian Malware Team primarily uses another version of BlackWorm called the Dark Edition (v2.1). BlackWorm v2.1 was released on a prolific underground forum where information and code is often shared, traded and sold.

syria8

BlackWorm v2.1 has the same abilities as the original version and additional functionality, including bypassing UAC, disabling host firewalls and spreading over network shares. Unlike its predecessor, it also allows for granular control of the features available within the RAT. These additional controls allow the RAT user to enable and disable features as needed. Binary output can be also be generated in multiple formats, such as .exe, .src and .dll.

syria9

BlackWorm Dark Edition builder

Syrian Malware Team

We observed activity from the Syrian Malware Team going as far back as Jan. 1, 2011. Based on Facebook posts, they are allegedly directly or indirectly involved with the Syrian government. Their Facebook page shows they are still very active, with a post as recent as July 16th, 2014.

syria10

Syrian Malware Team’s Facebook page

The Syrian Malware Team has been involved in everything from profiling targets to orchestrating attacks themselves. There are seemingly multiple members, including:

Partial list of self-proclaimed Syrian Malware Team members

Some of these people have posted malware-related items on Facebook.

syria11

Facebook posting of virus scanning of files

While looking for Dark Edition samples, we discovered a binary named svchost.exe (MD5: 015c51e11e314ff99b1487d92a1ba09b). We quickly saw indicators that it was created by BlackWorm Dark Edition.

syria12

Configuration options within code

The malware communicated out to 178.44.115.196, over port 5050, with a command structure of:

!0/j|n\12121212_64F3BF1F/j|n\{Hostname}/j|n\{Username}/j|n\USA/j|n\Win 7 Professional SP1 x86/j|n\No/j|n\2.4.0 [ Dark Edition]/j|n\/j|n\{ActiveWindowName}/j|n\[endof]

When looking at samples of Dark Edition BlackWorm being used by the Syrian Malware Team, the strings “Syrian Malware,” or “Syrian Malware Team” are often used in the C2 communications or within the binary strings.

Additional pivoting off of svchost.exe brought us to three additional samples apparently built with BlackWorm Dark Edition. E.exe, (MD5: a8cf815c3800202d448d035300985dc7) a binary that drew our attention, looked to be a backdoor with the Syrian Malware strings within it.

syria13

When executed, the binary beacons to aliallosh.sytes.net on port 1177. This C2 has been seen in multiple malware runs often associated with Syria.  The command structure of the binary is:

!0/j|n\Syrian Malware/j|n\{Hostname}/j|n\{Username}/j|n\USA/j|n\Win 7 Professional SP1 x86/j|n\No/j|n

\0.1/j|n\/j|n\{ActiveWindowName}/j|n\[endof]

Finally, pivoting to another sample, 1gpj.srcRania (MD5:f99c15c62a5d981ffac5fdb611e13095), the same strings were present. The string "Rania" used as a lure was in Arabic and likely refers to the prolific Queen Rania of Jordan.

syria14

The traffic is nearly identical to the other samples we identified and tied to the Syrian Malware Team.

!1/j|n\C:\Documents and Settings\{Username}\Local Settings\Application DataldoDrZdpkK.jpg - Windows Internet Explorer[endof]!0/j|n\Syrian Malware/j|n\{Hostname}/j|n\{Username}/j|n\USA/j|n\Win XP ProfessionalSP2 x86/j|n\No/j|n\0.1/j|n\/j|n\C:\Documents and Settings\{Username}\Local Settings\Application DataldoDrZdpkK.jpg - {ActiveWindowName}/j|n\[endof]

Conclusion

Determining which groups use which malware is often very difficult. Connecting the dots between actors and malware typically involves looking at binary code, identifying related malware examples associated with those binaries, and reviewing infection vectors, among other things.

This blog presents a prime example of the process of attribution. We connected a builder with malware samples and the actors/developers behind these attacks. This type of attribution is key to creating actionable threat intelligence to help proactively protect organizations.

  • There are no more articles
❌