Home   Blog   Twitter   Database  

What the cell...? Telcos around the world were so severely pwned, they didn't notice the hackers setting up VPN points

Revealed: Long-running espionage campaign targets phone carriers to snoop on VIPs' location, call records

Hackers infiltrated the networks of at least ten cellular telcos around the world, and remained hidden for years, as part of a long-running tightly targeted surveillance operation, The Register has learned. This espionage campaign is still ongoing, it is claimed.…

Posted: 24 Jun 2019 | 8:18 pm

RDP Security Explained

RDP on the Radar

Recently, McAfee released a blog related to the wormable RDP vulnerability referred to as CVE-2019-0708 or “Bluekeep.” The blog highlights a particular vulnerability in RDP which was deemed critical by Microsoft due to the fact that it exploitable over a network connection without authentication. These attributes make it particularly ‘wormable’ – it can easily be coded to spread itself by reaching out to other accessible networked hosts, similar to the famous EternalBlue exploit of 2017. This seems particularly relevant when (at the time of writing) 3,865,098 instances of port 3389 are showing as open on Shodan.

Prior to this, RDP was already on our radar. Last July, McAfee ATR did a deep dive on Remote Desktop Protocol (RDP) marketplaces and described the sheer ease with which cybercriminals can obtain access to a large variety of computer systems, some of which are very sensitive. One of the methods of RDP misuse that we discussed was how it could aid deploying a targeted ransomware campaign. At that time one of the most prolific targeted ransomware groups was SamSam. To gain an initial foothold on its victims’ networks, SamSam would often rely on weakly protected RDP access. From its RDP launchpad, it would proceed to move laterally through a victim’s network, successfully exploiting and discovering additional weaknesses, for instance in a company’s Active Directory (AD).

In November 2018, the FBI and the Justice department indicted two Iranian men for developing and spreading the SamSam ransomware extorting hospitals, municipalities and public institutions, causing over $30 million in losses. Unfortunately, this did not stop other cybercriminals from using similar tactics, techniques and procedures (TTPs).

The sheer number of vulnerable systems in the wild make it a “target” rich environment for cybercriminals.

In the beginning of 2019 we dedicated several blogs to the Ryuk ransomware family that has been using RDP as an initial entry vector. Even though RDP misuse has been around for many years, it does seem to have gained an increased popularity amongst criminals focused on targeted ransomware.

Recent statistics showed that RDP is the most dominant attack vector, being used in 63.5% of disclosed targeted ransomware campaigns in Q1 of 2019.

Source: Coveware Q1 statistics

Securing RDP

Given the dire circumstances highlighted above it is wise to question if externally accessible RDP is an absolute necessity for any organization. It is also wise to consider how to better secure RDP if you are absolutely reliant on it. The good news is there are several easy steps that help an organization to better secure RDP access.

That is why, in this blog, we will use the adversarial knowledge from the McAfee ATR red team to explain what easy measures can be undertaken to harden RDP access.

Recommendations are additional to standard systems hygiene which should be carried out for all systems (although it becomes more important for Internet connected hosts), such as keeping all software up-to-date, and we intentionally avoid ‘security through obscurity’ items such as changing the RDP port number.

Do not allow RDP connections over the open Internet

To be very clear… RDP should never be open to the Internet. The internet is continuously being scanned for open port 3389 (the default RDP port). Even with a complex password policy and multi-factor authentication you can be vulnerable to denial of service and user account lockout. A much safer alternative is to use a Virtual Private Network (VPN). A VPN will allow a remote user to securely access their corporate network without exposing their computer to the entire Internet. The connection is mutually encrypted, providing authentication for both client and server, preferably using a dual factor, while creating a secure tunnel to the corporate network. As you only have access to the network you will still need to RDP to the computer but can do so more securely without exposing it to the internet.

Use Complex Passwords

An often-used alternative acronym for RDP is “Really Dumb Passwords.” That short phrase encapsulates the number one vulnerability of RDP systems, simply by scanning the internet for systems that accept RDP connections and launching a brute-force attack with popular tools such as, ForcerX, NLBrute, Hydra or RDP Forcer to gain access.

Using complex passwords will make brute-force RDP attacks harder to succeed.

Below are the top 15 passwords used on vulnerable RDP systems. We built this list based on information on weak passwords shared by a friendly Law Enforcement Agency from taken down RDP shops. What is most shocking is the fact that there is such a large number of vulnerable RDP systems did not even have a password.

The TOP 15 used passwords on vulnerable RDP systems

[no password]

Use Multi-Factor Authentication

In addition to a complex password, it is best practice use multi-factor authentication. Even with great care and diligence, a username and password can still be compromised. If legitimate credentials have been compromised, multi-factor authentication adds an additional layer of protection by requiring the user to provide a security token, e.g. a code received by notification or a biometric verification. Better yet, a FIDO based authentication device can provide an extra factor which is not vulnerable to spoofing attacks, in a similar fashion to other one-time-password (OTP) mechanisms. This increases the difficulty for an unauthorized person to gain access to the computing device.

Use an RDP Gateway

Recent versions of Windows Server provide an RDP gateway server. This provides one external interface to many internal RDP endpoints, thus simplifying management, including many of the items outlined in the following recommendations. These comprise of logging, TLS certificates, authentication to the end device without actually exposing it to the Internet, authorization to internal host and user restrictions, etc.

Microsoft provides detailed instructions for configuration of remote desktop gateway server, for Windows Server 2008 R2 as an example, over here.

Lock out users and block or timeout IPs that have too many failed logon attempts

A high number of failed logon attempts is a strong indication of a brute force attack. Limiting the number of logon attempts per user can prevent such attacks. A failed logon attempt is logged under Windows Event ID 4625. An RDP logon falls under logon type 10, RemoteInteractive. The account lockout threshold can be specified in the local group policy under security settings: Account Policies.

For logging purposes, it is best to log both failed and successful logons. Additionally, it is important to note that “specific security layer for RDP connections” needs to be enabled. Otherwise, you will be unable to tell that the logon attempt came over RDP or see the source IP address. A comparison is shown below.

Event log network logon (type 3) note no source network address

Event log RDP logon (type 10) note the source network address present

Use a Firewall to restrict access

Firewall rules can be created to restrict Remote Desktop access so that only a specific IP address or a range of IP addresses can access a given device. This can be achieved by simply opening “Windows Firewall with Advanced Security,” clicking on Inbound Rules and scrolling down to the RDP rule. A screen shot can be seen below.

Firewall settings for inbound RDP connections 

Enable Restricted Admin Mode

When connecting to a remote machine via RDP, credentials are stored on that machine and may be retrievable by other users of the systems (e.g. malicious attackers). Microsoft has added restricted admin mode which instructs the RDP server not to store credentials of users who log in. Behind the scenes, the server now uses ‘network’ login rather than ‘interactive’ and therefore uses hashes or Kerberos tickets rather than passwords for authentication. Assessment of the pros and cons of this option are recommended before enabling in your environment. On the negative side, the use of network login exposes the possibility of credential reuse (pass the hash) attacks against the RDP server. Pass the hash is likely possible anyway, internally, via other exposed ports so may not significantly increase exposure there, but when including this option to Internet servers, where other ports are likely (and should be!) restricted, pass the hash is then extended to the Internet. Given the pros and cons, avoiding internal escalation of privilege is often prioritized and therefore restricted admin mode is enabled.

Microsoft TechNet describes configuration and usage of restricted mode here.


There are four levels of encryption supported by standard RDP: Low, Client Compatible, High, and FIPS Compliant. This is configured on the Remote Desktop server. This can be further improved upon by using Enhanced RDP Security. When Enhanced RDP security is used, encryption and server authentication are implemented by external security protocols, e.g. TLS or CredSSP. One of the key benefits of Enhanced RDP Security is that it enables the use of Network Level Authentication (NLA) when using CredSSP as the external security protocol.

Certificate management is always a complexity, but Microsoft does provide this through the use of Active Directory Certificate Services (ADCS). Certificates can be pushed using Group Policy Objects (GPO) where this is available. Incompatible operating system environments must import certificates via the web interface exposed at https://<server>/Certsrv.

Enable Network Level Authentication (NLA)

To reduce the amount of initially required server resources, and thereby mitigate against denial of service attacks, network level authentication (NLA) can be used. Within this mode, strong authentication takes place before the remote desktop connection is established, using the Credential Security Support Provider (CredSSP) either through TLS or Kerberos. NLA can also help to protect against man-in-the-middle attacks, where credentials are intercepted. However, be aware that NLA over NTLM does not provide strong authentication and should be disabled in favor of NLA over TLS (with valid certificates).

Microsoft TechNet describes configuration and usage of NLA in Windows Server 2008 R2 here.

Interestingly, BlueKeep, mentioned above, is partially mitigated by having NLA enabled. As reported by Microsoft in the associated advisory “With NLA turned on, an attacker would first need to authenticate to Remote Desktop Services using a valid account on the target system before the attacker could exploit the vulnerability.”

Restrict users who can logon using RDP

All administrators can use RDP by default. Remote access should be limited to only the accounts that require it. If all administrators do not need remote access you should consider removing the Administrator account from the RDP access group. You can then add the specific users which require access to the “Remote Desktop Users” group. See here for more information on managing users in your RDS collection.

Minimize the Number of Local Administrator Accounts

Local administrator accounts provide an attack vector for attackers who gain access to a system. Credentials can be cracked offline and more accounts means more likelihood of a successful crack. Therefore, you should aim for a maximum of one local administrator account which is secured appropriately.

Ensure that Local Administrator Accounts are Unique

If the local administrator accounts match those assigned to their counterparts on other systems within the server’s internal network, the attacker can potentially re-use credentials to move laterally. This issue occurs quite frequently, so Microsoft provided Local Administrator Password Solution (LAPS) as a means to avoid this scenario across the organization with central management of unique local administrator credentials. This is particularly relevant for externally exposed systems.

Microsoft provides a download and usage information for LAPS here.

Limit Domain Administrator Account Access

Accounts within the domain admins group have full control of the domain by default, by virtue of being part of the administrators group for all domain controllers, domain workstations and domain member servers. If a credential for a domain admin account is retrieved from the RDP server, the attacker now holds the ‘keys to the kingdom’ and is in full control of the entire domain. You should reduce the amount of domain administrators within the organization in general and avoid accessing the RDP server or other externally exposed systems via these accounts, to avoid inadvertently making credentials accessible.

In general, ‘least privilege’ administration models should be used. Microsoft provides guidance in this area, including how best to use domain admin accounts, here.

Consider Placement Within the Network

Where possible, RDP servers should be placed within a DMZ or other restricted area of the network. The idea here is that if an attack is successful, its scope is reduced and confined to the RDP server alone. Often RDP is exposed specifically to allow external users onto the network, so this may not be a feasible solution, however it should be considered and the quantity of services reachable within the internal network should be minimized.

Consider using an account-naming convention that does not reveal organizational information

There are many options for account naming conventions, ranging from firstname.lastname to not deriving usernames from name data; all having their pros and cons. However, some of the more commonly used account naming conventions such as firstname.lastname, make it very easy to guess usernames and email addresses. This can be a security concern as spammers and hackers will readily use this information.


When trying to run an efficient IT organization, having remote access to certain computer systems might be essential. Unfortunately, when not implemented correctly, the tools that make remote access possible also open your systems up to unwanted guests. In the last few years there have been far too many examples of where vulnerable RDP access gave way to a full-scale network compromise.

In this article we have shown that RDP access can be hardened with some easy steps. Please take the time to review your RDP security posture.

The post RDP Security Explained appeared first on McAfee Blogs.

Posted: 24 Jun 2019 | 9:50 am

Mozilla patched two Firefox zero-day flaws in one week

Two emergency zero days affecting a browser in one week counts as unusual - especially when they pop up as separate alerts two days apart.

Posted: 24 Jun 2019 | 4:17 am

CVE-2019-8635: Double Free Vulnerability in Apple macOS Lets Attackers Escalate System Privileges and Execute Arbitrary Code

by Moony Li and Lilang Wu (Threats Analysts)

We discovered a double free vulnerability (assigned as CVE-2019-8635) in macOS. The vulnerability is caused by a memory corruption flaw in the AMD component. If successfully exploited, an attacker can implement privilege escalation and execute malicious code on the system with root privileges. We disclosed our findings to Apple, which has since released a patch.

The CVE ID covers two flaws, namely in the discard_StretchTex2Tex method and processing of sideband tokens in an AMD Radeon class called AMDRadeonX400_AMDSIGLContext. It is the derived class of IOAccelGLContext2, which extends from IOAccelContext2 class. These classes are used to render graphics on macOS machines.

The vulnerability here occurs in the discard_StretchTex2Tex and AMDSIGLContext::process_StretchTex2Tex functions of the AMDRadeonX4000_AMDSIGLContext class, which can be accessed using the AMDRadeonX4000_AMDSIGLContext userclient with selector 2 function IOAccelContext2::submit_data_buffers, while the AMDRadeonX4000_AMDGraphicsAccelerator client can be opened with connect type 1.

AMDRadeonX4000_AMDSIGLContext discard_StretchTex2Tex Double Free Privilege Escalation Vulnerability

This vulnerability allows local attackers to execute code on userspace. To exploit this vulnerability, an attacker must first obtain the ability to execute low-privileged code on the target macOS system.

The flaw results from the lack of proper validation of user-supplied data, which in turn results in a read past the end of an allocated data structure. An attacker can take advantage of this, together with other vulnerabilities, to escalate privileges to the kernel level.

AMDRadeonX4000_AMDSIGLContext Double Free Privilege Escalation Vulnerability

A double free vulnerability also exists in the processing of sideband tokens in the same AMD class. The vulnerability allows local attacks to execute arbitrary code on affected installations of Apple macOS. As with the aforementioned flaw, an attacker must first obtain the ability to execute low-privileged code on the target system to take advantage of this one.

While the previously mentioned flaw occurs in the AMDRadeonX4000_AMDSIGLContext: discard_StretchTex2Tex function, this one is in the AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex function. It results from the lack of validation in the existence of an object prior to performing operations on the said object. An attacker can take advantage of this flaw to escalate privileges to the kernel level.

Essentially, the two flaws are similar in terms of possible exploitation, the difference is in the function taken advantage of.

Root Cause Analysis

Figure 1. The pseudo code snippet of AMDRadeonX4000_AMDSIGLContext: discard_StretchTex2Tex function (top), the pseudo code snippet of AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex function (bottom)

Figure 1 (top) shows that, if (cmdinfo+32) is equal to 0x8c00, the IOAccelResource v10 and v11 are both taken from IOAccelShared2, with *(shareMem_start_address_187_offset16+8) and *(shareMem_start_address_187_offset16+12) values as indexes. This function will then release two accelerator resources using the IOAccelResource2::clientRelease() function. However, these two indexes can be directly controlled from the userspace through map memory, with the IOAccelContext2 userclient. If userspace maps the same index for lookupResource function, clientRelease will release the same resource client twice, which is when the double free vulnerability occurs.

Figure 1 (bottom) shows that, if v15 is equal to 0x8c00, the accelResource_offset8 and accelResource_offset12 are both taken from IOAccelShared2, with shared memory offset 24 and 28 values as indexes. Finally, this function will release accelResource_offset12 from IOAccelShared2 _rst, and if accelResource_offset8->member2 is not equal to 10, this function will also release the accelResource_offset8 from IOAccelShared2. However, setting the shared memory offset 24 and 28 to the same value releases the same accelResource twice.

In process_StretchTex2Tex() function, completing the stretch operation will release two resource clients using the IOAccelResource2::clientRelease() function. However, these two accelResource2 are taken from accelShare2 shared memory within the AMDRadeonX4000_AMDSIGLContext class, using the IOAccelShared2::lookupResource function with each index. These indexes can be controlled from userspace by map memory with the IOAccelContext2 userclient. If userspace maps the same index for the lookupResource function, clientRelease will release the same resource client twice, which is when the double free vulnerability occurs.

The pseudo code snippets for both flaws show that the shared memory address points to command stream info offset 24. However, the command stream info buffer is actually set in the IOAccelContext2::processSidebandBuffer function, as shown in the next figure. In Figure 2, v5 points to shareMem offset 16, and this->member196 points to the commandStreamInfo offset 24.

Figure 2. The pseudo code snippet of IOAccelContext2::processSidebandBuffer

Figure 2. The pseudo code snippet of IOAccelContext2::processSidebandBuffer

Figure 3 is the pseudo code snippet of the IOAccelContext2::clientMemoryForType function. The function is called by known API “IOConnectMapMemory64”, which can map a userspace buffer to kernel space. When using the IOConnectMapMemory64 function, one should set the connect object, memory type, and other arguments. Here, connect object is the instance of IOAccelContext2, with memory type as 0, as shown in Figure 3. When we set the memory type to 0, the clientMemoryForType function will create a buffer memory descriptor and return the start address to userspace. Furthermore, it will also set the buffer memory address to the “shareMem_start_vm_address_187” var, which we named. This var is the exact value used in the IOAccelContext2::processSidebandBuffer function.

From there, the shared buffer can be controlled and the two resource indexes can be set similarly, which then triggers the double free bug.

Figure 3. The pseudo code snippet of the IOAccelContext2::clientMemoryForType function

Figure 3. The pseudo code snippet of the IOAccelContext2::clientMemoryForType function

The following provides the backtrace information in the application’s crash log, where only “AMDRadeonX4000`AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex” and the function offset “process_StretchTex2Tex(IOAccelCommandStreamInfo&) + 2893” will differ if the discard_StretchTex2Tex function is used.

* thread #1, stop reason = signal SIGSTOP
frame #0: 0xffffff7f8d7adc37 IOAcceleratorFamily2`IOAccelResource2::clientRelease(IOAccelShared2*) + 13
frame #1: 0xffffff7f8d880dad AMDRadeonX4000`AMDRadeonX4000_AMDSIGLContext::process_StretchTex2Tex(IOAccelCommandStreamInfo&) + 2893
frame #2: 0xffffff7f8d79b5d5 IOAcceleratorFamily2`IOAccelContext2::processSidebandBuffer(IOAccelCommandDescriptor*, bool) + 273
frame #3: 0xffffff7f8d8885e4 AMDRadeonX4000`AMDRadeonX4000_AMDSIGLContext::processSidebandBuffer(IOAccelCommandDescriptor*, bool) + 182
frame #4: 0xffffff7f8d79bae7 IOAcceleratorFamily2`IOAccelContext2::processDataBuffers(unsigned int) + 85
frame #5: 0xffffff7f8d7a2380 IOAcceleratorFamily2`IOAccelGLContext2::processDataBuffers(unsigned int) + 804
frame #6: 0xffffff7f8d798c30 IOAcceleratorFamily2`IOAccelContext2::submit_data_buffers(IOAccelContextSubmitDataBuffersIn*, IOAccelContextSubmitDataBuffersOut*, unsigned long long, unsigned long long*) + 1208
frame #7: 0xffffff800b027a3c kernel.development`::shim_io_connect_method_structureI_structureO(method=, object=, input=, inputCount=, output=, outputCount=0xffffff8742023968) at IOUserClient.cpp:0 [opt]
frame #8: 0xffffff800b025ca0 kernel.development`IOUserClient::externalMethod(this=, selector=, args=0xffffff87420239b8, dispatch=0x0000000000000000, target=0x0000000000000000, reference=) at IOUserClient.cpp:5459 [opt]
*frame #9: 0xffffff800b02ebff kernel.development`::is_io_connect_method(connection=0xffffff80b094e000, selector=2, scalar_input=, scalar_inputCnt=, inband_input=, inband_inputCnt=136, ool_input=0, ool_input_size=0, inband_output=””, inband_outputCnt=0xffffff80b0d81e0c, scalar_output=0xffffff8742023ce0, scalar_outputCnt=0xffffff8742023cdc, ool_output=0, ool_output_size=0xffffff80ab5c7574) at IOUserClient.cpp:3994 [opt]
frame #10: 0xffffff7f913044c2
frame #11: 0xffffff800a9bbd64 kernel.development`_Xio_connect_method(InHeadP=, OutHeadP=0xffffff8742023ce0) at device_server.c:8379 [opt]
frame #12: 0xffffff800a88d27d kernel.development`ipc_kobject_server(request=0xffffff80ab5c7400, option=) at ipc_kobject.c:359 [opt]
frame #13: 0xffffff800a859465 kernel.development`ipc_kmsg_send(kmsg=0xffffff80ab5c7400, option=3, send_timeout=0) at ipc_kmsg.c:1832 [opt]
frame #14: 0xffffff800a878a75 kernel.development`mach_msg_overwrite_trap(args=) at mach_msg.c:549 [opt]
frame #15: 0xffffff800a9f63a3 kernel.development`mach_call_munger64(state=0xffffff80af471bc0) at bsd_i386.c:573 [opt]
frame #16: 0xffffff800a823486 kernel.development`hndl_mach_scall64 + 22

In the event of a Mac system experiences a kernel panic, the panic text is added to a log. A kernel panic is a system error detected by the kernel (as opposed to similar errors detected by user space code) resulting from unhandled processor exceptions in kernel code, such as references to invalid memory addresses, or a bug in the call chain. The panic log, as follows, can be examined:

panic(cpu 6 caller 0xffffff800aa1391c): Kernel trap at 0xffffff7f8d7adc37, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000018, CR3: 0x0000000fea85f063, CR4: 0x00000000001626e0
RAX: 0x0000000000000000, RBX: 0xffffff800b473e28, RCX: 0x00000000ffffffff, RDX: 0x0000000000000000
RSP: 0xffffff8742023610, RBP: 0xffffff8742023610, RSI: 0xffffff80b0f8e470, RDI: 0xffffff80afa29300
R8: 0x0000000000000229, R9: 0xffffff800b2c4d00, R10: 0xffffff800b2c2c70, R11: 0x0000000000000058
R12: 0xffffff87299cb9b4, R13: 0x0000000000000001, R14: 0xffffff80b094e608, R15: 0xffffff80b094e000
RFL: 0x0000000000010282, RIP: 0xffffff7f8d7adc37, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000018, Error code: 0x0000000000000002, Fault CPU: 0x6, PL: 0, VF: 0

The following, meanwhile, shows the registers’ debug information of the kernel panic. $r12 register points to the shared memory address offset 16. The resource indexes are also both shown as 0x42.

(lldb) register read
General Purpose Registers:
rax = 0x0000000000000000
rbx = 0xffffff800b473e28 kernel.development`kdebug_enable
rcx = 0x00000000ffffffff
rdx = 0x0000000000000000
rdi = 0xffffff80afa29300
rsi = 0xffffff80b0f8e470
rbp = 0xffffff8742023610
rsp = 0xffffff8742023610
r8 = 0x0000000000000229
r9 = 0xffffff800b2c4d00 kernel.development`zone_array + 8336
r10 = 0xffffff800b2c2c70 kernel.development`zone_array
r11 = 0x0000000000000058
r12 = 0xffffff87299cb9b4
r13 = 0x0000000000000001
r14 = 0xffffff80b094e608
r15 = 0xffffff80b094e000
rip = 0xffffff7f8d7adc37 IOAcceleratorFamily2`IOAccelResource2::clientRelease(IOAccelShared2*) + 13
rflags = 0x0000000000010282
cs = 0x0000000000000008
fs = 0x00000000ffff0000
gs = 0x00000000afa20000

(lldb) x/20g $r12
0xffffff87299cb9b4: 0x00000364001a8c00 0x0000004200000042
0xffffff87299cb9c4: 0x0000104000000101 0x0055550000900002
0xffffff87299cb9d4: 0x0004000800040008 0x1048000000010001
0xffffff87299cb9e4: 0x0055560000900002 0x0002000800020008
0xffffff87299cb9f4: 0x0000000000010001 0x0000000000000000
0xffffff87299cba04: 0x0000000400000004 0x0000000000000000
0xffffff87299cba14: 0x0000000200000002 0x00000364001a8c00
0xffffff87299cba24: 0x0000004200000042 0x0000104800000101
0xffffff87299cba34: 0x0055560000900002 0x0002000800020008
0xffffff87299cba44: 0x1050000000010001 0x0055570000900002

Protecting Mac devices from possible CVE-2019-8635 exploitation

Attackers can use the double free vulnerability to attack unpatched macOS systems and compromise machines with elevated privileges. Apple has provided a fix for the memory corruption issue by improving memory handling. A security update is now available for macOS Mojave 10.14.4, and users are advised to upgrade their OS X as soon as possible. Users can also install solutions such as the Trend Micro Antivirus for Mac and Trend Micro Protection Suites that detect and block attack attempts that use various flaws.

The post CVE-2019-8635: Double Free Vulnerability in Apple macOS Lets Attackers Escalate System Privileges and Execute Arbitrary Code appeared first on .

Posted: 21 Jun 2019 | 5:00 am

HiddenWasp Linux malware backdoor samples

Here are Hidden Wasp Linux backdoor samples. 



Intezer HiddenWasp Malware Stings Targeted Linux Systems 


Download. Email me if you need the password (see in my profile)

File informatio




 elf shared-lib

64bits elf shared-lib



tar-bundle gzip contains-elf

 tar-bundle gzip

64bits elf 

Posted: 3 Jun 2019 | 9:31 pm

CyberESI at the 2019 NCSA and NASDAQ Cybersecurity Summit

“Incident Response and Recovery” was the theme of the National Cyber Security Alliance (NCSA) and NASDAQ Cybersecurity Summit on April 17 in New York City. Security and risk professionals from the Department of Homeland Security and various organizations convened at the Nasdaq Marketsite to discuss methods that focus on resilience and recovery following a cyber attack or data breach.

Matt Barrett, CyberESI’s chief operating officer, participated in a panel discussion focused on the topic of Reducing Uncertainty and Looking Beyond IT. “When you think about incident response and the parties involved … those who truly speak cybersecurity, really and truly speak cybersecurity, are in the minority,” said Barrett.

Read more at https://www.darkreading.com/risk/tips-for-the-aftermath-of-a-cyberattack/d/d-id/1334460 and https://staysafeonline.org/blog/incident-response-ncsa-nasdaq-cybersecurity-summit/

The post CyberESI at the 2019 NCSA and NASDAQ Cybersecurity Summit appeared first on CyberESI.

Posted: 30 Apr 2019 | 8:27 am

Introducing Reneo

Reneo is a Windows tool to help incident responders, forensics specialists, and security researchers analyze and reverse engineer malicious and obfuscated scripts and other content. This tool can convert from/to various formats, transform, deobfuscate, encode/decode, encrypt/decrypt, and hash strings. The … Continue reading

Posted: 27 Jun 2018 | 8:14 am

Freedome VPN For Mac OS X

Take a look at this:

F-Secure Freedome Mac OS X

F-Secure Freedome for OS X (freshly installed on a Labs Mac Team MacBook).


The beta is now open for everyone to try for 60 days at no cost.

Download or share.

On 24/04/15 At 12:37 PM

Posted: 24 Apr 2015 | 1:37 am