Hit with Malware?

Malware
  • I’ve created this dedicated tag to offer help with system infections - from minor to major, there is expertise here to assist.

    I heard from a friend recently who’s been hit pretty badly by a malicious actor, and after providing initial guidance over the phone, I thought it made sense to open this up for other members to make use of.

    Feel free to use it for advice, information, and anything else you think you may need.


  • 9 Votes
    12 Posts
    98 Views

    @crazycells said in ION brings clients back online after ransomware attack:

    you know, they believe the world revolves around them

    Haha, yes. And they invented sex.

  • 0 Votes
    1 Posts
    140 Views

    1622032930658-hacked_listen-min.webp

    I’ve been a veteran of the infosec industry for several years, and during that time, I’ve been exposed to a wide range of technology and situations alike. Over this period, I’ve amassed a wealth of experience around information security, physical security, and systems. 18 years of that experience has been gained within the financial sector - the remaining spread across manufacturing, retail, and several other areas. I’ve always classed myself as a jack of all trades, and a master of none. The real reason for this is that I wanted to gain as much exposure to the world of technology without effectively “shoehorning” myself - pigeon holing my career and restricting my overall scope.

    I learned how to both hack and protect 8086 / Z80 systems back in 1984, and was using “POKE” well before Facebook coined the phrase and made it trendy (one of the actual commands I still remember to this day that rendered the CTRL, SHIFT, ESC break sequence useless was

    POKE &bdee, &c9

    I spent my youth dissecting systems and software alike, understanding how they worked, and more importantly, how easily they could be bypassed or modified.

    Was I a hacker in my youth ? If you understand the true meaning of the word, then yes - I most definitely was.

    If you think a hacker is a criminal, then absolutely not. I took my various skills I obtained over the years, honed them, and made them into a walking information source - a living, breathing technology encyclopedia that could be queried simply by asking a question (but not vulnerable to SQL injection).

    Over the years, I took an interest in all forms of technology, and was deeply immersed in the “virus era” of the 2000’s. I already understood how viruses worked (after dissecting hundreds of them in a home lab), and the level of damage that could be inflicted by one paved the way for a natural progression to early and somewhat infantile malware. In its earliest form, this malware was easily spotted and removed. Today’s campaigns see code that will self delete itself post successful execution, leaving little to no trace of its activity on a system. Once the APT (Advanced Persistent Threat) acronym became mainstream, the world and its brother realised they had a significant problem in their hands, and needed to respond accordingly. I’d realised early on that one of the best defences against the ever advancing malware was containment. If you “stem the flow”, you reduce the overall impact - essentially, restricting the malicious activity to a small subset rather than your entire estate.

    I began collaborating with various stakeholders in the organisations I worked for over the years, carefully explaining how modern threats worked, the level of damage they could inflict initially from an information and financial perspective, extending to reputation damage and a variety of others as campaigns increased in their complexity). I recall one incident during a tenure within the manufacturing industry where I provided a proof of concept. At the time, I was working as a pro bono consultant for a small company, and I don’t think they took me too seriously.

    Using an existing and shockingly vulnerable Windows 2003 server (it was still using the original settings in terms of configuration - they had no patching regime, meaning all systems were effectively vanilla) I exhibited how simple it would be to gain access first to this server, then steal the hash - effortlessly using that token to gain full access to other systems without even knowing the password (pass the hash). A very primitive exercise by today’s standards, but effective nonetheless. I explained every step of what I was doing along the way, and then explained how to mitigate this simple exploit - I even provided a step by step guide on how to reproduce the vulnerability, how to remediate it, and even provided my recommendations for the necessary steps to enhance security across their estate. Their response was, frankly, shocking. Not only did they attempt to refute my findings, but at the same time, dismissed it as trivial - effectively brushing it under the carpet so to speak. This wasn’t a high profile entity, but the firm in question was AIM listed, and by definition, were duty bound - they had a responsibility to shareholders and stakeholders to resolve this issue. Instead, they remained silent.

    Being Pro Bono meant that my role was an advisory one, and I wasn’t charging for my work. The firm had asked me to perform a security posture review, yet somehow, didn’t like the result when it was presented to them. I informed them that they were more than welcome to obtain another opinion, and should process my findings as they saw fit. I later found out through a mutual contact that my findings had been dismissed as "“unrealistic”, and another consultant had certified their infrastructure as “safe”. I almost choked on my coffee, but wrote this off as a bad experience. 2 months later, I got a call from the same mutual contact telling me that my findings were indeed correct. He had been contacted by the same firm asking him to provide consultancy for what on the face of it, looked like a compromised network.

    Then came the next line which I’ll never forget.

    “I don’t suppose you’d be interested in……”

    I politely refused, saying I was busy on another project. I actually wasn’t, but refused out of principle. And so, without further ado, here’s my synopsis

    “…if you choose not to listen to the advice a security expert gives you, then you are leaving yourself and your organisation unnecessarily vulnerable. Ignorance is not bliss when it comes to security…”

    Think about what you’ve read for a moment, and be honest with me - say so if you think this statement is harsh given the previous content.

    The point I am trying to make here is that despite sustained effort, valiant attempts to raise awareness, and constantly telling people they have gaping holes in systems for them to ignore the advice (and the fix I’ve handed to them on a plate) is extremely frustrating. Those in the InfoSec community are duty bound to responsibly disclose, inform, educate, raise awareness, and help protect, but that doesn’t extend to wiping people’s noses and telling them it wasn’t their fault that they failed to follow simple advice that probably could have prevented their inevitable breach. My response here is that if you bury your head in the sand, you won’t see the guy running up behind you intent on kicking you up the ass.

    Security situations can easily be avoided if people are prepared to actually listen and heed advice. I’m willing to help anyone, but they in return have to be equally willing to listen, understand, and react.

  • 0 Votes
    1 Posts
    143 Views

    1621959888112-code.webp
    Anyone working in the information and infrastructure security space will be more than familiar with the non-stop evolution that is vulnerability management. Seemingly on a daily basis, we see new attacks emerging, and those old mechanisms that you thought were well and truly dead resurface with “Frankenstein” like capabilities rendering your existing defences designed to combat that particular threat either inefficient, or in some cases, completely ineffective. All too often, we see previous campaigns resurface with newer destructive capabilities designed to extort both from the financial and blackmail perspective.

    It’s the function of the “Blue Team” to (in several cases) work around the clock to patch a security vulnerability identified in a system, and ensure that the technology landscape and estate is as healthy as is feasibly possible. On the flip side, it’s the function of the “Red Team” to identify hidden vulnerabilities in your systems and associated networks, and provide assistance around the remediation of the identified threat in a controlled manner.

    Depending on your requirements, the minimum industry accepted testing frequency from the “Red Team” perspective is once per year, and typically involves the traditional “perimeter” (externally facing devices such as firewalls, routers, etc), websites, public facing applications, and anything else exposed to the internet. Whilst this satisfies the “tick in the box” requirement on infrastructure that traditionally never changes, is it really sufficient in today’s ever-changing environments ? The answer here is no.

    With the arrival of flexible computing, virtual data centres, SaaS, IaaS, IoT, and literally every other acronym relating to technology comes a new level of risk. Evolution of system and application capabilities has meant that these very systems are in most cases self-learning (and for networks, self-healing). Application algorithms, Machine Learning, and Artificial Intelligence can all introduce an unintended vulnerability throughout the development lifecycle, therefore, failing to test, address, and validate the security of any new application or modern infrastructure that is public facing is a breach waiting to happen. For those “in the industry”, how many times have you been met with this very scenario

    “Blue Team: We fixed the vulnerabilities that the Red Team said they’d found…” “Red Team: We found the vulnerabilities that the Blue Team said they’d fixed…”

    Does this sound familiar ?

    What I’m alluding to here is that security isn’t “fire and forget”. It’s a multi-faceted, complex process of evolution that, very much like the earth itself, is constantly spinning. Vulnerabilities evolve at an alarming rate, and unfortunately, your security program needs to evolve with it rather than simply “stopping” for even a short period of time. It’s surprising (and in all honesty, worrying) the amount of businesses that do not currently (and even worse, have no plans to) perform an internal vulnerability assessment. You’ll notice here I do not refer to this as a penetration test - you can’t “penetrate” something you are already sitting inside. The purpose of this exercise is to engage a third party vendor (subject to the usual Non-Disclosure Agreement process) for a couple of days. Let them sit directly inside your network, and see what they can discover. Topology maps and subnets help, but in reality, this is a discovery “mission” and it’s up to the tester in terms of how they handle the exercise.

    The important component here is scope. Additionally, there are always boundaries. For example, I typically prefer a proof of concept rather than a tester blundering in and using a “capture the flag” approach that could cause significant disruption or damage to existing processes - particularly in-house development. It’s vital that you “set the tone” of what is acceptable, and what you expect to gain from the exercise at the beginning of the engagement. Essentially, the mantra here is that the evolution wheel in fact never stops - it’s why security personnel are always busy, and CISO’s never sleep 🙂

    These days, a pragmatic approach is essential in order to manage a security framework properly. Gone are the days of annual testing alone, being dismissive around “low level” threats without fully understanding their capabilities, and brushing identified vulnerabilities “under the carpet”. The annual testing still holds significant value, but only if undertaken by an independent body, such as those accredited by CREST (for example).

    You can reduce the exposure to risk in your own environment by creating your own security framework, and adopting a frequent vulnerability scanning schedule with self remediation. Not only does this lower the risk to your overall environment, but also provides the comfort that you take security seriously to clients and vendors alike whom conduct frequent assessments as part of their Due Diligence programs. Identifying vulnerabilities is one thing, however, remediating them is another. You essentially need to “find a balance” in terms of deciding which comes first. The obvious route is to target critical, high, and medium risk, whilst leaving the “low risk” items behind, or on the “back burner”.

    The issue with this approach is that it’s perfectly possible to chain multiple vulnerabilities together that on their own would be classed as low risk, and end up with something much more sinister when combined. This is why it’s important to address even low-risk vulnerabilities to see how easy it would be to effectively execute these inside your environment. In reality, no Red Team member can tell you exactly how any threat could pan out if a way to exploit it silently existed in your environment without a proof of concept exercise - that, and the necessity sometimes for a “perfect storm” that makes the previous statement possible in a production environment.

    Vulnerability assessments rely on attitude to risk at their core. If the attitude is classed as low for a high risk threat, then there needs to be a responsible person capable of enforcing an argument for that particular threat to be at the top of the remediation list. This is often the challenge - where board members will accept a level of risk because the remediation itself may impact a particular process, or interfere with a particular development cycle - mainly because they do not understand the implication of weakened security over desired functionality.

    For any security program to be complete (as far as is possible), it also needs to consider the fundamental weakest link in any organisation - the user. Whilst this sounds harsh, the below statement is always true

    “A malicious actor can send 1,000 emails to random users, but only needs one to actually click a link to gain a foothold into an organisation”

    For this reason, any internal vulnerability assessment program should also factor in social engineering, phishing simulations, vishing, eavesdropping (water cooler / kitchen chat), unattended documents left on copiers, dropping a USB thumb drive in reception or “public” (in the sense of the firm) areas.

    There’s a lot more to this topic than this article alone can sanely cover. After several years experience in Information and Infrastructure Security, I’ve seen my fair share of inadequate processes and programs, and it’s time we addressed the elephant in the room.

    Got you thinking about your own security program ?