Malicious actors operate command-and-control (C&C/C2) servers to interact with their victims’ computers. These C2 servers are intended to instruct the compromised PCs to do undesired things, such as stealing the user’s passwords, encrypting the files for ransom or attacking other computers on the network.
We learned from the previous article that SOCs/Incident Response teams should be looking for threats that represent high-level risks to the normal business activities.
We know the who, but how can we define what needs to be protected?
Assume your company has over a thousand business applications. They are hosted in multiple data centres as well as in the cloud. There are Windows and Linux hosts, and many of these are not patched of course. On top of that, nobody knows who owns them.
The following article cuts through this complexity and explains a simple approach.
Psst! Do you wanna protect your company from security incidents?
But what you have is hundreds of apps, your infrastructure looks like a bowl of spaghetti and the company is short on resources? Don’t worry, it’s doable with careful planning!
This risk-based incident response framework lets you target the most critical things at your organisation. Keep on reading and your incident response team will operate as a powerful sniper rifle, rather than a clunky shotgun.
Forming a Computer Security Incident Response Team (CSIRT) is a complex affair. It normally involves a certain combination of staff, processes and technologies.
However the essentials are the same in most situations, no matter what the mission of your CSIRT is. This publication attempts to provide a list of must-have technologies for all forming incident response teams out there.
I took the recently leaked git repos from of Hacking Team from GitHub and ran them through a couple of static code analysis tools.
Manual analysis has successfully unfolded a few 0days. Hopefully these results may assist further research.
While Hacking Team was cleaning up the mess, security professionals were raging on Twitter. The company was publicly shamed for its bad passwords, worse reaction and questionable business practices on social media.
But was it really necessary to post random screenshots of private emails from the 400 Gb pack, totally out of context? Or mock HT employees because of something they already knew? Dumping their source code on GitHub?
Thoughts on the recent breach at Hacking Team, privacy and responsible behavior of security professionals