Multiple sources have reported the breach of Cisco’s own network, purportedly via a Cisco employee’s personal Google account. According to multiple sources, the employee in question was saving and syncing both personal and Cisco business credentials to the Google Chrome browser for ease of access. Once the employee’s personal Google account was compromised, the bad guys accessed the Chrome password history, harvested the Cisco business credentials, and were off to the races.
This situation further enforces the need for better, more frequent end user awareness education and the monitoring of employees to ensure bad practices are not in play. At the end of the day, we are all human and we will all make mistakes. We can only get better if we train more, talk more, and monitor effectively.
The following article from ThreatPost is a great overview of the situation and provides an interesting recap of how the bad guys overcame the Cisco VPN MFA controls. Enjoy the read and beware of these threats! TRAIN YOUR PEOPLE!!
I very much enjoyed this article from Pieter Danhieux via Dark Reading and this creative approach to the management of applications and hierarchical security. The concept of least privilege and the dangers of API controls are often discussed but frequently forgotten when developing and revising an overall security framework for an organization. Enjoy the read!
A zero-day vulnerability in Microsoft Office was discovered and reported over the weekend that involves remote code execution simply through the opening of a Word document, even in preview. Microsoft has issued CVE-2022-30190 in response to this flaw, though this bug is generally being referred to as the Follina vulnerability. When the malicious Word document is opened even in preview, the file executes malicious PowerShell commands via Microsoft Diagnostic Tool (MSDT). This code works without elevated privileges and is currently evading Microsoft Defender detection.
The following are several blog posts and updates concerning this vulnerability, its functionality, and workarounds in the absence of a patch:
Given the tragedies of the last few weeks, I thought it would be an appropriate time to reshare some of the active shooter content from this site over the last few years. Now more than ever, it is an important time to be prepared and trained for these types of incidents.
Given the recent tanking of bitcoin value in the open market, you might think that the criminal exploitation of private computers for coin mining might start to slow, but I guess the cyber bad guys in the world need to compensate for their value loses and mine new coins.
This article from the great team over at InfoSecurity is a great overview. Enjoy and beware!
All large, modern military operations are heavily reliant on satellites to provide a variety of logistics and planning information related to battlefield operations. That information includes GPS coordination and navigation, topographic imaging, drone command & control, and many other surveillance functions. Threats to Russia’s satellite infrastructure by those in opposition to the invasion and ongoing conflict in Ukraine have prompted Russian officials to respond and to respond harshly.
The following article from the great team at InfoSecurity details the Russian response / denial to hacking attempts against their satellite infrastructure:
Simply put, military conflicts are not what they used to be. So far during the conflict in Ukraine, we have seen the Russian space authority make a less than vailed threat against the safety of the International Space Station. We have also seen the delay and/or cancellation of satellite launches from Russian space facilities for agencies, governments, and organizations that oppose Russian activity in Ukraine. There are many factors to take into consideration, both short term and long term, when considering orbital resources and the effect this ongoing conflict can and will have on national and international assets in space.
Russia is still a primary partner in the ISS program and still provides the primary transportation and recovery services for the space station. Those services will most likely be on hold for the foreseeable future. The Russian space agency also provides satellite launch services for many nations and private agencies around the world. Those services have become a bargaining chip for international negotiations moving forward.
It will be very interesting to watch these situations develop over the weeks and months to come. We are seeing the Cold War rekindle and acts of fiction from recent TV shows and movies begin to come to life as scenarios play out on the “final frontier”.
As strange as this may sound, military attacks are no longer simply about soldiers and tanks and planes and bombs. Needless to say, there is nothing simple about war, but thanks to state sponsored hacking and the connected nature of critical infrastructure, cyber warfare has become a new front for every new military conflict. The conflict brewing in Ukraine is no different.
Threat levels have been raised by numerous national and international cybersecurity organizations, and malicious cyber activity is already being monitored related to this current conflict. Please remember that the types of attacks associated with these nation state conflicts are not perfectly crafted and restricted to only military targets. They can overflow into civilian networks that can quickly spread around the world in a matter of hours. NotPetya is a wonderful example of targeted cyber warfare run amuck.
Take the time to prepare your environments and make sure all your controls are in place and up to date. The Internet is staged to see quite a bit of malicious cyber activity in the days and weeks to come.
This article from the team at Dark Reading is an excellent overview of the challenges and approaches to DR testing as well as great reminder of the value and influence of the human factor. All successful disaster recovery planning starts with people – its all about teamwork, collaboration, and communication during an event.
We are well into the second week of reaction and remediation associated with the Apache Log4j vulnerability, so I wanted to pause and take a moment to recap what we know, what we should be doing now, and what we should be considering moving forward. Let us start with what we know.
Log4j is a remote code execution (RCE) vulnerability that can force the download of a malicious payload on vulnerable web servers and computers depending on the presence and/or configuration of certain server components. Specifically, exploitation of the vulnerability requires a single HTTP request containing malicious input from anywhere in the world, to an internet-facing server that is running a vulnerable instance of log4j, or the same HTTP request sent to a vulnerable computer within a compromised local network. The result is a full system compromise, and the exploit requires no authentication. It is important to stress that the Log4j vulnerability is not limited to Internet-facing web servers only. If a bad actor gains access to a local network, the same HTTP requests can be sent internal to IP-enabled devices on that network to compromise vulnerable systems. This is a very serious potential attack vector, and all of us should be working diligently to ensure all our devices and those of our friends, family, and clients are safe and properly protected.
So what should we be doing now. First and foremost, we should all be scanning our computers, servers, and other IP-enabled devices to look for vulnerable versions of Log4j. At this point, there are numerous scanning tools available from security experts, RMM vendors, and other platforms from which to choose. Please remember that these scanning tools take different approaches to identifying potentially vulnerable systems and devices. Some look for the presence of Log4j associated jar files. Others look for log entries on the device indicating the presence of malicious inbound activity. And then others actually send crafted HTTP requests looking for vulnerable system responses. Given these different detection methods, make sure to understand your scan results and take the time to verify the findings before you start pulling systems, servers, and devices offline.
Once you verify the presence of a vulnerable Log4j component, the next step involves determining why the component is present on that system or device and then reaching out to the application or device vendor to find updates, patches, and/or mitigation instructions. Log4j is so ubiquitous in applications, servers, and IP-enabled appliances, and application vendors and IoT vendors have embedded it and leveraged it hundreds of different ways, so vendor support may be a necessity to ensure you properly remediate the problem.
Once you have remediated the Log4j vulnerability on all your IP-enabled systems and devices, what do you do next? It is at this point that we all need to stop, document what we have done, take stock of what worked and what did not, and then be prepared to do it all over again in the future. The Log4j vulnerability is not going away. Scanning for this particular vulnerability needs to become part of your overall vulnerability management program. You will inevitably purchase new applications, devices, and systems and you need to ensure Log4j, if used, is properly updated (version 2.16 or later at this point in the component evolution). Also, as you work with your application vendors moving forward, some may try to convince you that the risk of Log4j only applies to web-exposed servers and devices. This statement is simply not true. Push back against these statements. Push back hard.
Nothing I have said about vulnerability management in this article is new, and nothing is particularly unique to Log4j. Scan your networks regularly (at least quarterly – more frequently if possible) and review those scan reports. Remediate your findings. If a finding cannot be remediated, budget for a replacement application or device. Keep your applications, components, and operating systems up to date. Cybercriminals are not going away. They don’t take vacations, and they don’t care how many other projects you are working on that prevented you from vulnerability remediation this month or this quarter. The threats are real and we all have to keep playing great defense. Good Luck!
The following is a great webpage from U.S. CERT on Log4j and associated resources: