Tag Archives: Security

Scams and Fraud: How Business Owners Can Avoid All Forms of Attack

Today’s guest post was submitted by Dean Burgess from Exitepreneur. Thanks, Dean!

Scams and fraud perpetrated by thieves who want to gain access to a company’s data or content cause millions of dollars of loss each year for businesses large and small. Sadly, no matter how many precautions you take against it, it’s likely that you’ll face some form of theft over the course of your company’s lifetime. With advances in technology happening every day, scammers have many more tools than they used to, making access to your computers and payment systems much easier. When this happens, private and sensitive data can be breached, leaving you responsible for large sums of money and breaking the trust you’ve built with your client base.

Fortunately, there are things you can do to avoid some of these scams and ways you can protect yourself against being hit again if you’ve already suffered an attack. It’s important to take a look at the way your company does business, and that includes determining who has access to sensitive materials such as credit card numbers and email passwords. Even if an employee isn’t purposely being dishonest, they may be playing an unsuspecting role in allowing others to gain unrestricted access to your system and data.

To keep your company and customers safe, here are a few things to consider.

When Phishing Results in a Big Loss

Phishing scams, which are perpetrated by email and used by scammers to gain information about a business that they can exploit, can result in huge losses. Unfortunately, if your company is a small one, this can mean big trouble. If you’ve been the victim of a phishing scam, it’s a good idea to go with a professional tech support company like Secure Data Recovery to help you recover that data. This is the best option when you need to get back up and running in a short amount of time. When your business is small, that time can be crucial to minimizing loss.

Train Your Employees

It’s imperative to make sure that your employees are well-trained and thoroughly understand how to spot a scam, especially the employees who have access to your company’s email address. These emails can be difficult to spy if you aren’t sure what to look for, so it’s a good idea to make sure your business email is with a reputable and secure provider. This way, many of these email scams will be caught before you ever see them. Of course, they can still get through, so teaching your employees what to look for will be essential. Grammatical and spelling errors are a major red flag, as are emails that are not specifically addressed to someone at the business.

Stay Up on the Trends

There are always new and inventive scams making their way around the web, and for this year, the ones to look out for include emails informing you that a certain account has had a suspicious login or that your account has expired. When you click the link they provide, you’re actually taken to a faux page that records your information. You should also be on the lookout for text messages and messages within apps; fraud can occur here, too.

Don’t Be Intimidated

One common form of fraud that many business owners have faced recently is an email or visit from a pushy salesperson who insists that someone from the company ordered supplies that must be paid for. Some will call a company claiming to be with Google and try to intimidate an employee into sending them payment in order to have the company show up in searches. Don’t let these scammers intimidate you! Train your employees to recognize a fraudulent claim, and let them know what to do in the event that they are the victim of one.

Scams and fraud are more common than many business owners may know, so it’s important to remember that just because you haven’t been hit before is not a guarantee that you never will be the victim of a crime. Training your employees well and taking precautions will help you keep your company — and your clients and customers — safe.

CMS-DH Admin Login Bypass


This information is also available on Github.

CMS-DH is an old generic application created for resale, probably by Dahua or one of it’s divisions. It is used to control Digimerge security cameras. Now Flir owns Digimerge and everybody wants to forget this software exists. In reality it doesn’t matter and I don’t really care. There are configuration entries to change the name of the application in toolbar menu’s, so that should give you an idea of how generic it was meant to be.

If you lose access to CMS-DH it can be extremely difficult to connect to the DVR and make changes to it. The documentation for Digimerge hardware is practically non-existent, and the company itself doesn’t exist anymore (now absorbed into Flir Security, who don’t even have a TLS cert on their security-centric website). The lack of information presents a problem that is compounded by the fact that there seem to be different versions of documentation out there for the Digimerge equipment and not many of them seem to have accurate or useful information.

Luckily, the hardware uses CMS-DH to make configuration changes from a computer. CMS-DH is what I like to call “third world software” meaning that it was written without any consideration for security, nobody wants to own support for it, and it hangs all it’s secrets out there in the open.


This hack was tested to work with…..

App Version:

Service Version:

Codec Version:

Download Dll Version:

…..Although I’m not sure of a way to find this info until you log in at least once.

CMS-DH stores configuration data in C:\Users\USERNAME\Documents\CMS-DH. The “.ems” files in this folder contain the configuration data for CMS-DH and can be opened in Notepad or any other text editor.

In order for the hack to work, you must have a copy of CMS-DH installed and configured with devices and an admin connection to a DVR. This hack will only give you access to CMS-DH. If CMS-DH is connected to devices (using the device password) you will have access those devices once you gain access to CMS-DH. If CMS-DH is not connected to any devices this won’t get you anywhere. This hack is only valuable on a pre-configured CMS-DH that you do not have credentials for.

To gain access to CMS-DH without valid login credentials you must open “registry.ems” with a text editor and locating the “PASSWORD=” line.

The “PASSWORD=” line contains the user password in hashed form. If you look a little further down you’ll see another line that starts with “LOGINAC=” followed by a plain text username.

Start by backing up “Registry.ems” and then wipe out the hashed password string from the “PASSWORD=” line. So “PASSWORD=54883fsdf83nn2nb4” would become simply “PASSWORD=”. Save the file and launch CMS-DH. It will start the application and bypass the login screen.


We know that an attacker can wipe out the cached password from CMS-DH and that it will completely skip the login screen. An attacker can leverage this to gain access to DVR’s they shouldn’t have authorization to by obtaining a copy of someone else’s CMS-DH config directory. Because all the config data for devices are stored in the CMS-DH config directory, a successful attacker would have everything they need to log into gain unauthorized access to a local security system.

Possible attack vectors for stealing the directory include…..

  1. Phishing the user and convincing them to send you CMS-DH “log files.”
  2. Misconfigured Windows Share.
  3. Boot to USB and copy/paste unencrypted HDD contents.
  4. Make the user run a script which dumps the contents of the CMS-DH directory somewhere.
  5. Gain access to the machine (physical or remote) and exfiltrate the files to a CNC server.
  6. The files are small enough to exfiltrate through a DNS TXT query.

Windows Accessibility Tools… For Hackers Too???

I enjoy listening to the Darknet Diaries podcast by Jack Rhysider. In a recent episode a guest of the show was telling a story about how he managed to compromise a computer network while in prison for… You guessed it! Hacking.  Anyway, the story of the hack isn’t what I wanted to discuss with you in this blog post. Instead, I wanted to talk about the hack itself, the vulnerability that it exploits, and how you can stop it with some simple scripting.

Setting The Stage

The hack involves the accessibility tools built into Windows. An attacker with physical access to your machine can abuse them at your Windows logon screen to do pretty much whatever they want. I know what you’re thinking, “But if the attacker already has physical access, why bother?” You have a point. Most attackers who have physical access to a machine will be able to gain control over that machine. This is true in almost every scenario. An attacker with physical access can almost always find some workaround to undermine your security. Whether they use a removable device, brute force attacks, or just plain-old-taking the cover off and making off with the disk drives… You’d be hard pressed to beat an attack when the attacker has your equipment and you don’t.

But there are circumstances where a potential attacker has physical access but still lacks the time, privacy, or tools to pull off an attack. Like in prison, where you have to be covert or guards will spot you. Or at work, where your co-workers might ask how you managed to get into the BIOS of a company computer, or at school where the librarian might ask why you’re taking her computers apart. These are all places where internal attacks become too risky and/or time-consuming to pull off. The Accessibility Tools hack is one where you need to enter the BIOS of the machine and reboot several times. That takes a while, and although the skill level of the attack is low, it’s still a very dangerous proposition to have an attacker with local admin access on your network. Lets setup a sandbox scenario…You’re a domain administrator named Bob with 50 machines on your network. Someone has pulled off an Accessibility Tools hack on a machine and has local admin rights whenever they want. They install a keylogger on the machine and forget about it until 3 days later you get a ticket to take a look at the machine because someone can’t get into their email. You log on remotely but nothing is broken. You sip your coffee and work up the nerve to go teach this person how to use their email. You make your way to the machine and, without thinking twice, blast your domain admin credentials into their machine in the process of helping them. Now the attacker has your domain admin credentials, and they don’t even need physical access anymore.

The Hack
So, back to the attack. You start off with a USB thumb drive. Install your favorite flavor of Linux Live onto it so you can boot straight into a root shell. I like the Trinity Rescue Kit for this type of thing, because it comes with tons of tools like Windows password resetting, ClamScanning, and tons more.
Next, boot the target machine to the USB stick where you installed Linux. If you have it boot right into a shell, great! If not, get to a shell, and make it root! Next mount the local Windows filesystem somewhere and use cp or rm to get “/Windows/System32/Magnify.exe” out of the way. Then cp or mv “/Windows/System32/cmd.exe” to “/Windows/System32/Magnify.exe.” The commands you use depend on stealth/time constraints and how much the you care about putting things back later. You can also use any of the other accessibility tools to achieve the same attack.

Next reboot the machine and load the accessibility tool that you replaced with cmd.exe. You now have a SYSTEM command prompt. Because the file is owned by TrustedInstaller, it’s extremely difficult to modify this in a production domain environment with a standard user account, but if you can find a computer with USB ports enabled and an unprotected BIOS this should be relatively easy to pull off.

The Defense
There are several prerequisites that need to be in-place for this attack to work.
  1. BIOS password disabled.
  2. USB ports enabled.
  3. Removable storage (CD/USB/floppy) set before primary OS boot device in BIOS.
  4. Accessibility Tools at logon screen enabled by Group Policy Management or Local Group Policy Editor.
If number 4 from the list above combines with number 1 or 3 then the conditions exist for Accessibility Tool exploits. So the easiest way out of this mess might just be to flip-the-switch on numbers 1 and 3 using built-in Windows functionality, or disable number 4 either on a standalone machine using the Local Group Policy Editor, or on a domain network using Group Policy Management.
Of course the easiest way isn’t always the best way. The Accessibility Tools do provide valuable features. I can’t tell you how many times the on-screen-keyboard has helped me fix laptops that took spills, or get around dead keyboard batteries, or diagnose machines with wonky drivers. Group Policy can control which machines get which policies, so it’s possible to be selective… but I’d rather just leave them on incase someone needs them. We can figure out a programmatic solution for this problem.

The Script
We need to develop a script for detecting this attack. As far as attacks go, this one is pretty noisy. Moving around Windows files in the System32 directory is the hacker equivilent of sticking your head out of the trenches. Since we know specifically which files are going to be affected we should be able to simply diff some hashes and check for file existence to be sure there was no tampering. Other possible metrics to use for tamper detection include filesize caching/diff’ing and date modified caching/diff’ing. By checking, caching, or simply hardcoding a predicted filesize or date modified we can compare the cache or hardcoded data with the current ecosystem. If things aren’t exactly the way we left them, we know someone’s tampered with the system.

Option Explicit

oShell, oFSO, dangerousExes, exe, cmdHardCodedHash, cmdDynamicHash,
strComputerName, strUserName, strLogFilePath, strSafeDate, _
 strSafeTime, strDateTime, strLogFileName, strEventInfo, objLogFile, cmdHashCache, objCmdHashCache, dangerHashCache, _
 dangerHashData, mailFile, objDangerHashCache, oFile

Set oShell = WScript.CreateObject(“WScript.Shell”)
Set oFSO = CreateObject(“Scripting.FileSystemObject”)
dangerousExes = Array(“Magnify.exe”, “Narrator.exe”, “osk.exe”, “sapisvr.exe”, “control.exe”, “utilman.exe”)
cmdHardCodedHash = “db 06 c3 53 49 64 e3 fc 79 d2 76 31 44 ba 53 74 2d 7f a2 50 ca 33 6f 4a 0f e7 24 b7 5a af f3 86”
cmdDynamicHash = “”
strComputerName = oShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strUserName = oShell.ExpandEnvironmentStrings(“%USERNAME%”)
strLogFilePath = “\\server\Logs”
strSafeDate = DatePart(“yyyy”,Date) & Right(“0” & DatePart(“m”,Date), 2) & Right(“0” & DatePart(“d”,Date), 2)
strSafeTime = Right(“0” & Hour(Now), 2) & Right(“0” & Minute(Now), 2) & Right(“0” & Second(Now), 2)
strDateTime = strSafeDate & “-” & strSafeTime
strLogFileName = strLogFilePath & “\” & strComputerName & “-” & strDateTime & “-Accessibility_Defender.txt”
cmdHashCache = “C:\cmdHashCache.dat”
dangerHashCache = “C:\dangerHashCache.dat”
mailFile = “C:\Accessibility_Defender_Warning.mail”

‘A function to clear the previous dangerCache and create a new one.
Function clearCache()
  If oFSO.FileExists(dangerHashCache) Then
  End If
  If Not oFSO.FileExists(dangerHashCache) Then
  End If
End Function

‘A function to create the CMD Hash Cache file.
Function getCmdHash()
  If oFSO.FileExists(“C:\Windows\System32\cmd.exe”) Then

oShell.run “cmd /c CertUtil -hashfile “”C:\Windows\System32\cmd.exe””
SHA256 | find /i /v “”SHA256″” | find /i /v “”certutil”” > ” &
cmdHashCache, 0, TRUE
  End If
End Function

‘A function to hash each of the hardcoded files and cache the value.
Function getDangerHash()
  For Each exe In dangerousExes
    If oFSO.FileExists(“C:\Windows\System32\” & exe) Then

oShell.run “cmd /c CertUtil -hashfile “”C:\Windows\System32\” & exe
& “”” SHA256 | find /i /v “”SHA256″” | find /i /v “”certutil””
>> ” & dangerHashCache, 0, TRUE
    End If
End Function

‘A function to read the CMD hash cache.
Function cmdHashData()
  If oFSO.FileExists(cmdHashCache) Then
    Set objCmdHashCache = oFSO.OpenTextFile(cmdHashCache)
    cmdHashData = objCmdHashCache.ReadAll()
  End If
End Function

‘A function to read the Danger hash cache and compare it to the CMD hash cache and hardcoded CMD hash.
Function hashMatch()
  hashMatch = FALSE
  If oFSO.FileExists(dangerHashCache) Then
    Set objDangerHashCache = oFSO.OpenTextFile(dangerHashCache)
    Do While Not objDangerHashCache.AtEndOfStream
      dangerHashData = objDangerHashCache.ReadLine()
      If dangerHashData = cmdHashData() Or dangerHashData = cmdHardCodedHash Then
        hashMatch = TRUE
      End If
  End If
End Function

Obviously, like all good programmers, we’re going to want to log the results of our script. I like to keep a centralized log location for all my network wide scripts so that I can breeze through it every few hours to spot problems.
‘A function to create a log file.
Function createLog(strEventInfo)
If Not (strEventInfo = “”) Then
Set objLogFile = oFSO.CreateTextFile(strLogFileName, True)
End If
End Function
Ok, so we have a good idea of how we can detect and keep track of these issues. But how can we stop it? The damage has already been done. We need an administrator to come investigate. A lot of old school Windows script blogs will tell you to use the deprecated Microsoft schemas for sending emails with Windows scripting languages, but I prefer Fake Sendmail For Windows by Byron Jones. It’s small, lightweight, and easy to use. Especially programmatically. I like to write my emails to a file and then execute sendmail on the file. That way there’s an intrinsic logging process built-in when the script leaves the sent mail message file behind. You will need to download this program and copy all of its files to your project folder.

Function createEmail()
If oFSO.FileExists(mailFile) Then
End If
If Not oFSO.FileExists(mailFile) Then
End If
Set oFile = oFSO.CreateTextFile(mailFile, True)
oFile.Write “To: IT@COMPANY.com” & vbNewLine & “From: server@COMPANY.com” & vbNewLine & _
“Subject: COMPANY Accessibility Defender Warning!!!” & vbNewLine & _
“This is an automatic email from the COMPANY Network to notify you
that a workstation was defended from Accessibility Tools exploitation.”
& _
vbNewLine & vbNewLine & “Please log-in and verify that the equipment listed below is secure.” & vbNewLine & _
vbNewLine & “USER NAME: ” & strUserName & vbNewLine &
“WORKSTATION: ” & strComputerName & vbNewLine & _
“This check was generated by ” & strComputerName & ” and is
performed when Windows boots.” & vbNewLine & vbNewLine & _
“Script: “”Accessibility_Defender.vbs”””
End Function’A function for running SendMail.
Function sendEmail()
oShell.run “cmd /c sendmail.exe ” & mailFile, 0, TRUE
End Function

Now we’ve detected an exploit in-progress and notified our IT department. We still have an attacker on a vulnerable machine staring down the sights of a loaded root shell with our machine on the receiving end. The only thing we can really do is log what’s happening to this machine and shut it down in the attackers face. He can always turn it back on, but it will just power off again once our script executes.
‘A function to kill the machine.
Function killWorkstation()
oShell.Run “cmd /c C:\windows\system32\shutdown.exe”, 0, false
End Function
Awesome! Now we’ve created all of the functionality we need and it’s all neatly organized into cohesive functions that we can call. It’s now time to write the bread-and-butter of our script. This is going to control the flow of our application and run all of the functions we made in the desired order. Note the conditional statement that executes if one of the Accessibility Tools has been compromised.
hashMatch()If hashMatch = TRUE Then
createLog(“The machine ” & strComputerName & ” just attempted to execute an Accessibility Tools exploitation!”)
End If

The Victory Lap
Now our attacker is a deer in the headlights. He’s staring at a broken shutdown loop that he probably realizes he created, and IT is probably on the way. Typically when I write scripts that write data to the log directory I like to add the username that generated the log as well, but in this case that’s not possible because the script runs on machine startup, before a user has logged in.
And there you have it! We’ve just written our own heuristic tool for determining when someone is messing around on our network. You should still seek to password protect the BIOS’s in your organization and remove all the boot devices except for the primary OS drive. If possible, consider disabling unpopulated USB ports. If that’s impossible without creating mutiny, try to make a script of your own to detect when someone plugs in a USB device. I made one that sends me an email and writes a log whenever someone plugs in a storage device. It could easily be modified to reject certain devices, or quietly scan them in the background for large file changes or sensitive data your business doesn’t want exfiltrated. That’s a project for another day.
When you’re an administrator you’ve got the best team in the entire company on your side…. The equipment. Don’t work hard, work smart… And make your equipment work hard for you.