I’m working an issue with a customer at the moment who contracted a computer virus which spread through their whole network, killing all machines on it. This includes servers and workstations.
Here’s what I can tell you:
- The virus itself appears to be present in the file c:\windows\samsam.exe
- A process monitor shows when it runs, it creates a file in c:\windows\prefetch (presumably to run itself on startup) as SAMSAM.EXE-<RANDOM>-PF
- It enumerates your directories and then begins encrypting files using the Windows Cryptography API.
- It creates the file c:\windows\system32\selfdel.exe
- It creates c:\windows\del.exe, which is a copy of the SysInternals SDELETE tool. It then runs the command “c:\windows\del.exe -c C: /accepteula” to wipe the free space on the disk, preventing recovery.
- Once this is done, it then wipes the samsam.exe application off disk.
- Unlike many variants of Cryptolocker, this one spreads through some yet-to-be-determined manner to other machines on the network. I have it disconnected and thus cannot see how it connects to other machines (or, if it perhaps just overwrote an executable on a network drive).
- Unlike any variant of Cryptolocker I’ve seen – it spreads to servers and runs on them as background processes, even stopping the Exchange databases and attempting to encrypt them (however, on this customer’s >1TB datastore, it just renamed it – perhaps it renames, encrypts to a temporary file and then copies over?).
- It will break the Symantec Endpoint Protection install on the machine to an unusable state.
- It is (as of this immediate moment) not detectable using Symantec Endpoint Protection or Webroot.
I am opening a ticket with Symantec and working it to provide them with the executable and process traces to get this puppy identified but for now – no Symantec tool we’ve ran picks it up.
I love SonicPoints! They are one of my favorite local wireless solutions and I’ve found them to be pretty darned reliable over time. But like anything, issues can creep in causing problems with your setup. Having said that, here’s my picklist of typical fixes for Sonicpoint issues.
- PoE Issues: The older Sonicpoint devices are 802.3af/PoE/15.4w devices, whereas the newer Sonicpoint devices are 802.3at/PoE+/25.5w compliant. This is often overlooked and they’ll power up on a lower-powered port anyway, but often will reset frequently as the power draw approaches the switch maximum. Make sure you’re using the proper injector/switch for the device. Also – remember that longer runs means more voltage drop.
- Spanning Tree: When a switch port becomes active, the spanning tree protocol will discard traffic until it determines the STP state of the connected device. For some switches, this can mean a fifteen second delay (or more) between when the device sees the link active and when traffic actually passes over it. Sometimes, the SonicPoint doesn’t get a reply from the Sonicwall fast enough and fails. Put the port in portfast mode (or turn off spanning tree for that port).
- EEE/Energy Efficient Ethernet: I know this is an odd mention, but many switches have EEE turned on by default when shipped and it’s not something many people think about, but the switch will scale the transmit voltages to what it thinks is the minimum required to work. Sometimes, it guesses wrong and you end up losing carrier.
- L2/L3 Issues: The L2/L3 network available to the Sonicpoint at boot-time should be dedicated to SonicPoint management (i.e. there should be nothing else on the network). On my devices, I dedicate a physical port to the SonicPoint traffic (to avoid bandwidth competition with the LAN), carry the untagged traffic on that interface to the SonicPoints and VLAN off each SSID. That way, devices aren’t messing around with the SonicPoint management traffic on either an L2 or L3 level.
- WAN Management: Don’t forget your SonicPoint management network will need internet access – including functional DNS – to update their firmware.
- Firewall Rules: There are some hidden assumptions in the Sonicwall firmware, like preventing wireless devices from talking to one another. When in doubt, check the Packet Monitor to ensure traffic is not being blocked by a firewall rule.
- DHCP: Twice encountered, it’s best to let the Sonicwall do any DHCP relaying over your network switch(es). I’ve seen issues with traffic not generated by the Sonicwall not making it to the client (which is configurable in the Sonicwall but a caveat nevertheless).
- Don’t be afraid to factory default. I’ve had SonicPoints go awry and after numerous power-cycles, a factory default left it resolved.