Most Attacks Don't Generate Security Alerts: Mandiant

[Stopspying]

Content source

https://www.securityweek.com/most-attacks-dont-generate-security-alerts-mandiant

"An analysis conducted by FireEye’s Mandiant Security Validation team revealed that only a small percentage of attacks generate alerts and many intrusions are not detected by security solutions.
The 2020 Mandiant Security Effectiveness Report is based on attack simulations targeting enterprise production environments across 11 sectors. The tests covered 123 security technologies and the targeted environments support more than 900 million consumers."

Most Attacks Don't Generate Security Alerts: Mandiant | SecurityWeek.Com

An analysis conducted by FireEye’s Mandiat revealed that only 9% of attacks generated security alerts and 53% of successful intrusions went undetected

www.securityweek.com

 

[Parsh]

For anyone wanting to checkout the non-executive full report.

There often is a brand-driven interest in carrying out tests that consolidate deficiencies in the industry scenario involving major players. This comes from FireEye having ties with the CIA that owns a small stake.

During the tests conducted by Mandiant, only 9% of attacks generated security alerts, and 53% of successful intrusions remained undetected. Just over a quarter of attacks were detected after the infiltration was successful, and only 33% of breaches were prevented by existing security tools.

A little point to note is that generating alerts is not the same as detection. They've used the terms throughout, to raise the point.
And sure, every organization would want reliable data on the status of their systems.

The cybersecurity firm’s experts determined that in many cases security tools are not optimized, which can be a result of unchanged default configurations, security events not making it to the security information and event management (SIEM) solution, unexpected infrastructure changes, the lack of tuning and tweaking after deployment, and the inability to force controls testing.

a Fortune 500 company discovered that while events were detected by its security solutions, data about these events did not make it to the SIEM due to the fact that UDP was used instead of TCP to send the data and a misconfigured load balancer dropped all UDP traffic. In another example, an insurance firm’s security tools were misconfigured and allowed over one-third of malicious file transfer attempts, and the attempts that were blocked did not trigger any alerts in the SIEM.

Here goes some sense of (false) security down the hill. After choosing an appropriate object for business interest (the security appliances), it is so important to look around them too. Having a solution and keeping men to check graphs and logs ain't enough.
There are many other factors to scrutinize and keep checking as per your infrastructure, configuration, and requirements — to make sure that the object will wholesomely keep working as intended.
A number of businesses have unique, differently operating teams that need to be kept up with an evolving, robust monitoring. And there needs to be lesser rift if any, between the IT Infrastructure department and the teams involved in Cybersecurity operations.

 

[Vitali Ortzi]

For anyone wanting to checkout the non-executive full report.

There often is a brand-driven interest in carrying out tests that consolidate deficiencies in the industry scenario involving major players. This comes from FireEye having ties with the CIA that owns a small stake.


A little point to note is that generating alerts is not the same as detection. They've used the terms throughout, to raise the point.
And sure, every organization would want reliable data on the status of their systems.


Here goes some sense of (false) security down the hill. After choosing an appropriate object for business interest (the security appliances), it is so important to look around them too. Having a solution and keeping men to check graphs and logs ain't enough.
There are many other factors to scrutinize and keep checking as per your infrastructure, configuration, and requirements — to make sure that the object will wholesomely keep working as intended.
A number of businesses have unique, differently operating teams that need to be kept up with an evolving, robust monitoring. And there needs to be lesser rift if any, between the IT Infrastructure department and the teams involved in Cybersecurity operations.

Look at Kaspersky duqu 2.0 attack made their appliances failed limited logging unknown amount of data taken .

 

[Parsh]

Look at Kaspersky duqu 2.0 attack made their appliances failed limited logging unknown amount of data taken .

Ah yes, that! But I wouldn't simply say limited logging is to blame.
It's common for businesses (unlike home users) to rely more on advanced logging, anomaly detection and restriction policies than blacklisting.
However good the system-and-network monitoring is, the outcome of logging pretty much depends on the designated personnel being able to filter and interpret any anomalies from among a ton of output data. And that's not easy. As you stated about the infamous Duqu 2.0 attack, there were interesting revelations that came much after. And K was not the only target.

The alleged state sponsored attack (won't get into the suspects, politics) used Windows Kernel and a Kerberos protocol exploit (3 exploits in total).
Intriguingly, Kaspersky discovered the compromise when their experts were testing a new technology to detect APTs (also an opportunistic marketing for a future product?).
Later, some logs helped unveil additional details about the attack pattern, now that those would make more sense.
It started with a spear phishing (targeted) attack against a K employee in a small office. Similar to Duqu, they used a Word exploit to directly gain access to the kernel (a kernel exploit using a zero-day vulnerability). Why the security program of the employee (must be K right?) could not flag the Word exploit might be a question. Was it totally undetected or manually allowed... but that was the start of the doom. Later it used another exploit to spread laterally.

And how it persisted? The malware used a stolen valid certificate of Foxconn. And the resultant driver was installed as a regular system service that could bypass the x64 Authenticode signature model of Microsoft. That's huge! But not impossible to even be explained.
Many under-the-radar pieces of puzzles combined, made it one of the most sophisticated attacks even K had ever seen. Duqu 2.0 used unknown kernel exploits and digitally signed network drivers to persist, hijack traffic routes, and send encrypted data attached to harmless network payload via proxies — to get the inked logs downplayed and gain persistence. The proxying of gateways and firewalls was a big bugger that was left undetected for quite a while.
A big bet, wasn't it for the attacker?

The experts suspect that it all started with a classic spear phishing attempt because one the “victims zero” they identified had its mailbox and web browser history wiped to avoid detection. Experts at Kaspersky confirmed that the infection stage was similar to the one implemented by Duqu that relied on malicious Word Documents containing an exploit for a zero-day vulnerability (CVE-2011-3402).
Duqu relied on an exploit that allowed the attackers to jump directly into Kernel mode from a Word Document, a technique considered by researchers very powerful and extremely rare.

Authors of Duqu 2.0 used a stolen certificate from the Foxconn company to implement a persistence mechanism and remain under the radar.
“The attackers created an unusual persistence module which they deploy on compromised networks. It serves a double function – it also supports a hidden C&C communication scheme. This organization-level persistence is achieved by a driver that is installed as a normal system service.”
“During their operations the Duqu threat actors install these malicious drivers on firewalls, gateways or any other servers that have direct Internet access on one side and corporate network access on the other side. By using them, they can achieve several goals at a time: access internal infrastructure from the Internet, avoid log records in corporate proxy servers and maintain a form of persistence after all,” continues the post.
The C&C mechanism relies on the usage of network pipes and mailslots, raw filtering of network traffic and masking C&C traffic inside image files. To connect the C&C servers, both 2011 and 2014/2015 versions of Duqu can hide the traffic as encrypted data appended to a harmless image file.
“It also doesn’t directly connect to a command-and-control server to receive instructions,” explained Kurt Baumgartner, principal security researcher at Kaspersky Lab. “Instead, the attackers infect network gateways and firewalls by installing malicious drivers that proxy all traffic from internal network to the attackers’ [command and control servers]. Combined, this made discovery very difficult.”

“Another interesting observation is that besides these Duqu drivers we haven’t uncovered any other malware signed with the same certificates,” the researchers continued. “That rules out the possibility that the certificates have been leaked and are being used by multiple groups.. which strengthens the theory they hacked the hardware manufacturers in order to get these certificates.”