Saturday, October 27, 2018

Ransomware Attacks: Pre and Post Attack Protection

I was contacted by a company that had been infected with ransomware that encrypted their servers' files and demanded money to provide decryption. The company's entire infrastructure was infected, including the backup server which backed files onto internal disks, so the backup was encrypted and inaccessible as well.

Below is a screenshot of the display showed on every server, instructing the victim of the situation and how to reach the attacker for decryption "services." I've masked the code so the victim wouldn't be identified and prone to revenge attack again.



The company that was attacked did have an antivirus in place, a firewall and some security measures, but that didn't prevent the attack. The attack occurred after the attackers spear-phished one of the admins and when the admin opened the attachment, the infection spread like wildfire.

Though an encrypted file sample was submitted to the ID Ransomware free service, unfortunately, it wasn't detected. When submitting your sample, give screenshots, emails and other related info. Even if it's not identified, it helps block such attacks in the future. The victim in this case ended up paying to decrypt 1 server (the backup) and didn't decrypt others. Wiped out all systems and started restoring.

Mistakes


  1. Servers ran unpatched Windows OSs. They were vulnerable to an old vulnerability that Microsoft had patched earlier this year in network sharing protocol SMBv1 that caused many malwares to spread via network.
  2. The backup software stores backups as files (which is fine), and those were stored on the internal disks only.

Positive Actions

  1. The owner contacted friends who were techies, who knew techies or who had been victims of similar incidents in the past.
  2. Did not touch any of the systems and left them as is. This is important, as some infections can be reversed if the server isn't rebooted (encryption key stays in memory sometimes).
  3. Contacted a local ISP that provided on-site security consultation. The person who attended there knew what to look for and that greatly helped identify the infection method.
    It's important to contact an external entity to look at your systems. Sometimes your admins will hide info to protect themselves and this does more damage than good for everyone: the company and the admins themselves.
  4. Contacted the attackers and act desperate (even if you aren't) to buy some time, and sometimes you can buy sympathy from your case handler (attacker replying to your email) and offer reduced price for decryption instead of paying full amount.

Protections and Precautions

  1. If you do pay to decrypt your data, fully understand that you're still infected, but now have access to your files. This does not mean you're safe, as the ransomware is still on your systems. You need to disinfect or completely wipe everything after getting your data out, and only the data without OS files.
  2. Always keep your systems up to date. Always. Force the business units or management to allocate suitable downtime for regularly patching all systems. Have procedures for critical patches that need to be applies ASAP and cannot wait for the usual schedule.
  3. Avoid running old operating systems. If you have software that must run on an archaic OS, find an alternative. Investing in migrating from old software that keeps you crippled is a lot cheaper than falling victim due to attacks on legacy systems, and running maintenance costs of legacy systems.
  4. When discovering an infection in the infrastructure, alert management immediately. Also, collect as many logs from as many systems as possible:
    1. Firewall logs
    2. VPN logs
    3. Server hardware logs
    4. Operating System events and logs
    5. Antivirus logs
  5. If the servers are running in your own datacenter in your building, disconnect everything from network, but keep the servers running. At least this prevents further spread or reinfection.
  6. Use latest version of an antivirus, not only updated signatures. You must always have the latest version of the application itself to make use of better self-defense mechanisms and detection methods.
  7. Use an antivirus on servers and PCs that has Application Control and Trusted Application Mode modules. I know Kaspersky and Bitdefender offer these, but some others sure do.
    Trusted Application Mode is most important to only allow verified and known applications to work, while blocking everything else. This way, should a malware reach a server, it won't be able to run there.
  8. Have an offline/off-site backup, either on some backup service, such as Veeam Cloud Backup, or on tape cartridges.
    If you decide to ship your tape cartridges abroad or take them outside of your building, make sure you place them in an anti magnet compartment to prevent metal detectors or Explosive Detection Systems (EDS) from damaging the tape. X-Ray is completely safe and does not emit any magnetic field, so it's safe to carry cartridges in your carry-on, but not your checked-in luggage that is subject to EDS, and not when in your pockets, as you go through metal detectors.
  9. Linux is also susceptible to ransomware, not only Windows. Keep your *nix systems patched.

It's important that one plans for worst case scenarios. Don't protect the perimeter from the outside, and leave the inside vulnerable. Live under the assumption that your internal systems can, and will, be infected one day, so plan accordingly.

Feel free to leave a comment to share your story, or an insight to help others, if you've been in a similar situation before.

Be paranoid. Be safe.

Tuesday, October 9, 2018

Unlock The Hidden Data: Enterprise Microservices Seminar

IBM is organizing a technical event to show use cases of containers, API consumption and micro-services in enterprise environments.

The event will have live demos and the speaking/presenting panel consists of technical engineers, and the though the agenda is brief, the audience is free to ask for specific demos of use cases or features.

The event will hold place at Sirdab Lab on Sunday Oct 14th, 5 PM to 8 PM. Attendance is free, but registration is required to provide sufficient seating and catering.

Event Information & Registration Link: https://www.eventbrite.com/e/unlock-the-hidden-data-enterprise-microservices-tickets-51119341326

Friday, September 7, 2018

Migrating Windows Fileservers: Preserving NTFS and Domain Controller Permissions

A client was running a Windows 2008 fileserver. Share folders have been created and used for years, and permissions were set per group or per user over the many folders, linked to Active Directory domain controller.

For this particular case, the shares were on a dedicated drive that is a storage mapped volume. Reassigning the volume from the old server to a new one is quite easy, but the tricky part was preserving the share settings and the NTFS permissions along with the active directory domain controller security permissions.

After much digging around, the solution was a builtin command line that can backup the permissions, and exporting a registry key to backup the configurations of the shares and their paths. Make sure you test this on a test machine first before applying to production! This will save both local users and domain controller security permissions.

Pay attention to back slashes (\) as it makes a difference to the tool.

Step 0: Backup and Restore Shares and their Permissions


  • Run regedit with administrator permission: search for regedit then right click and choose "Run as Administrator"
  • Go to this location:  HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
    Note: HKLM = HKey_Local_Machine
  • Right click the Shares registry key and export. The key that looks like a folder in the left pane, not the content inside on the right pane.
To restore the shares and their permissions, double click the saved exported file.

Step 1: Backup and Restore NTFS and Active Directory Security Permissions

  • Open the command prompt (cmd.exe) with administrator permission.
  • To backup: icacls "path to folder" /save ntfsperms.txt /t /c 2> errors.txt
    Example: icacls d:\data /save ntfsperms.txt /t /c 2> errors.txt
    /t for recursion to include subfolders of the main one.
    /c to continue even when errors occur, but they'll printed and written to the errors text file.

    Note: If you put multiple folders directly on the root of the drive, the command should look like this: icacls d:\* /save ntfsperms.txt /t /c 2> errors.txt
To restore: icacls d:\ /restore ntfsperms.txt

Yes, there's a difference in the way you restore the permissions and the path. Even if you had backed up d:\data, you restore to the root directory/folder d:\. That's how the tool works.

Keep in mind that the text file you'll save the permissions to will exist in the same place where it's showing the command prompt. If you run the cmd as Admin, you'll be in C:\Windows\System32 by default.