Skip to content
Team Acalvio
|
February 7, 2019
Deceiving Attackers in a Kubernetes World
Applications are moving to cloud-native Kubernetes-based platforms, come hell or high water, lift-and-shift as stateful apps or rewrite into a microservice design. Now what? The malware and threads follow the applications to these cloud native platforms. As the Tesla breach in 2018 showed, it was relatively easy for attackers to infiltrate the Kubernetes console, access privileged information and run custom workloads. Consequently, in this new environment, we have new vulnerabilities to detect and patch, new intrusion attempts to detect, and new remedial measures to undertake. While much of this can be achieved with a rigorous SecOps playbook, the detection of attackers or attacks is significantly harder. Conventional detection schemes that monitor all activity to single out suspicious ones, however, are plagued with high false positives that overwhelm the administrators and false negatives in ignoring cleverly disguised attackers. The industry has found deception technology, or honeypots as they are more commonly known, as a much more effective mechanism for detection. The main idea of using deception technology to lure attackers is to mirror real applications, without affecting the real applications, in the production infrastructure. Once mirrored, we rollout out a copy, called a decoy, that no legitimate user should be accessing, and include references, called breadcrumbs, to lure in attackers to these decoys. Rollout of decoys is incredibly hard to do in clouds; see for example the challenges in deploying a convincing AWS honeytoken that an attacker cannot expose as a fake. In the case of Kubernetes based workloads, it is considerably easier to deploy a convincing decoy workload for two reasons. First, we have plenty of information, captured within Kubernetes and Helm descriptors, about the production application and its dependencies that we intend to mirror; typical details found in these descriptors of an application include the pod name, service name, service ports, replication count, environment variables, and access privileges. These descriptors are easier to mirror, tweak and recreate, either within a new namespace or the existing production namespace. Second, many of the cloud native applications use open-source software (e.g., MongoDB, Jenkins, ElasticSearch) for which the descriptors and details are already available in public domain, making it easier to ensure the fidelity of the mirroring. Let’s look at an example to better understand application mirroring for deception. We rolled out the guestbook app within a GKE Kubernetes cluster and adopted a 4 step process for introducing deception alongside it: 1) Discover, where we extract information about the cluster and the applications already running, 2) Deploy, where we design and deploy the effective decoys as pods and services, 3) Inject, where we deploy the breadcrumbs in the form of ConfigMap or Ingress entries, 4) Track, where we monitor the various accesses to the decoys from internal and external attackers, and raise appropriate alarms. The first three steps use the Kubernetes API, and the last step uses the Acalvio ShadowPlex system. We show above a snapshot of the Kubernetes dashboard with the production services and decoy services deployed together. Can you spot the decoy entries? Like you, an attack will find it non-trivial to identify as fake our decoys (mysql and account-mgr pods and services) and breadcrumbs (account-mgr service and ingress entry). This is exactly what an effective deception looks like! While we made it look easy, it is still challenging to tailor these deceptions to the environment and to detect attackers in real-time. Stay tuned for a follow up blog with more details on how we solve this for you!
Read More
Team Acalvio
|
January 25, 2019
Unified Security in Hybrid Clouds: The Role of Kubernetes & Microservices
Enterprise workloads are rapidly migrating from on-prem data centers or private clouds towards public clouds, run by players such as Amazon and Microsoft. While CIOs and IT leaders have been spending the past few years reeling in these individual public cloud islands, it is increasingly becoming clear that enterprise infrastructure is going to be hybrid in nature and better to fully embrace the notion that enterprise infrastructure will span private clouds, and multiple public clouds. Considering each variant of the cloud has a different management, operational and security model, it is hard to achieve a common security posture that CIOs are comfortable with. There is, however, some reprieve in the horizon, thanks to another orthogonal transformation well underway among developer communities, wherein developers are porting applications to a platform that is common across all clouds. Specifically we’re referring to the redesign of applications to use the microservice design pattern and being dockerized to run over the open-source Kubernetes platform. This porting over will allow enterprises to run application as-is in any Kubernetes cluster within private cloud (e.g., vanilla-K8S, OpenShift, PKS), or public cloud (e.g., EKS, AKS, GKE). Why will having a common platform across clouds enable having a strong security posture? Two reasons. Firstly, in a common platform the nuances of underlying cloud are abstracted away and the capabilities, privileges, identities, tokens, accesses are all those configured in the Kubernetes layer, allowing for easier control, management and auditing. This also means that any security solution deployed to protect a Kubernetes workload is equally portable across clouds. Secondly, applications expose their dependencies in a common format (viz., Kubernetes/Helm descriptors and operators) allowing for easier posture assessment and enforcement. Being able to understand application behavior in a proactive manner allows for much more fine-tuned security measures. While there will always be cloud-specific resources that the applications consume (e.g., AWS S3, GCP DataProc) causing heterogeneity that poses challenges to the posture, the convergence of the applications under a common runtime abstraction helps make tremendous headway into securing the applications. This is more so true from a malware detection point of view, as learned first hand by our efforts in exploring the place of deception technology in the Kubernetes based microservice workloads. More in a follow up blog. Stay tuned.
Read More
Team Acalvio
|
October 15, 2018
Dynamic Deception to address GDPR compliance
Organizations are just starting to come to grips with the new European Union privacy law, GDPR. Following a flurry of emails and website warnings asking people to acknowledge updated data use policies (which virtually no one reads anyway), the question is “What do we do next?!” Although the situation appears complex and unclear (because it is), it’s possible to chart out some reasonable next steps when it comes to IT security. The first thing to keep in mind is that GDPR is vague when it comes to specifics for security. Article 32 is the key part of the law: “The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: The pseudonymisation and encryption of personal data; The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” That’s it. While in theory there are provisions for how to refine this vague article into something more specific, none of that is in place yet. (If you want follow progress in this area, start tracking “GDPR Codes of Conduct”, and the process of BSI 10012:2017 to become an international standard) However GDPR also contains a number of “recitals”. The recitals attempt to explain the basic goals of the law, and can be used to clarify things when the details (such as Article 32) are unclear. When it comes to IT Security, Recital 83 is key: “…the [organization] should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.” So our advice is to use this recital as your guideline. Implement a risk-based methodology to implement a control set that if operationalized and documented consistently should provide a reasonable security level. Then if something does go wrong, you can leverage the implementation of these controls to demonstrate a reasonable attempt to comply with GDPR. Coincidentally, our ShadowPlex distributed deception solution goes a long way down this path, with multiple controls supported in a single, highly scalable solution: Network monitoring for threat behavior Threat identificationThreat forensics and methods gathering Risk and impact determination Incident mitigation and containment Control testing Want to know more? Check out our GDPR Whitepaper to learn more about GDPR and how Acalvio can help achieve compliance quickly and reliably, or contact us for a demo.
Read More
Team Acalvio
|
August 18, 2018
Rise Above the Fray with The NIST Cybersecurity Framework
Being a CISO these days isn’t easy. The threats are dynamic, the technology hype bewildering, and the expectations from the boss to magically “just make the problem go away” unrelenting. One way to help get a grip on this mess is to adopt industry accepted frameworks in which to operate. The idea is to step back from the day to day world of budgets, phishing and recruiting and look at your desired security outcomes holistically. It’s certainly a more systematic approach than trying to figure out what your organization has implemented to date, and then figure out what’s worth keeping and what the gaps are. Perhaps the best guidance for security comes from the Cybersecurity Framework, or CSF. Although published by the US National Institute of Standards and Technology (NIST) to help “critical infrastructure” organizations (think power plants and such) the CSF is gaining wide adoption across the private sector. Industry surveys from the likes of Gartner and Cisco indicate increasing use of the framework. That’s because it’s not overly complex and supports prioritizing controls based on business risk. It’s also quite comprehensive, with five high-level outcomes: Identify, Protect, Detect, Respond, and Recover. Note that the outcomes address all phases of cybersecurity, including post-compromise activities. At Acalvio we advocate the use of the CSF, and have crafted our solutions to support 14 of the CSF controls. The starting point is detection. A key portion of the CSF is dedicated to the outcome of detecting attackers after they are inside the network, which is Acalvio’s bread and butter. Our ShadowPlex offering is focused on scalable, operationally realistic detection of threats. This includes attempts to access attractive but fake host assets created by ShadowPlex, as well as lateral movement and propagation across the network. But we don’t stop at detection: Acalvio has also pioneered engagement technologies that fall under the Cybersecurity Framework’s Respond and Recover sections. These technologies provide valuable insight about an attacker’s methods so that you can start attack mitigation quicker and more effectively. Meanwhile, our Shadow Network component slows the attacker down, providing more time to organize your response and update your prevention controls to block a new attack. We encourage you to review the Cybersecurity Framework, no matter what your level of security acumen. The truth is that it’s all too easy to get caught up in tactical firefighting or the latest wiz-bang product. All security practitioners need to carve out time to think strategically, and when you’re finally able to do that, you need a solid framework in which to work most efficiently…before the next fire breaks out!
Read More
using deep learning for information security p1
Team Acalvio
|
June 13, 2018
Using Deep Learning for Information Security – Part 1
Authors: Balamurali A R and Satnam Singh   Post Web 2.0, data generated on the internet has increased manifold. This has led to the use of data driven approaches to solve many traditional problems across different industry verticals. Among them, deep learning-based (DL) approaches have been quite impactful in recent times.  With powerful yet inexpensive hardware enabling millions of calculations to optimize parameters, DL algorithms have been successfully tackling problems in vision, language, operations research etc., to name a few. Deep learning is a type of machine learning that learn from experience and understand the world in terms of a hierarchy of concepts [1, 2]. It applies different neural network architectures to learn the concepts from a large data samples over time using a lot of parallel computations. Deep learning is an advanced representational learning that learns complicated concepts by building a graph of many deep layers each representing simple concepts in a hierarchy. With more context available, the deep learning-based systems perform even better than human. It has made significant advances in the problems where the accuracies were weak, and real-world usage was impossible. For example, classifying images, identifying objects, translating speech, automatically tagging photos, etc. In these applications, deep learning has made a significant improvement in achieving high accuracies, and therefore it is now used in online advertising, search engines, chatboxes, video games, computer vision, robotics, finance, and bioinformatics, and genomics. Deep learning is not a silver bullet that can solve all the InfoSec problems because it needs extensive labeled datasets and no such labeled datasets are readily available. However, there are several InfoSec use cases where the deep learning networks are making significant improvements to the existing solutions. Figure 1: Use Cases of Deep Learning in Information Security As discussed earlier, deep learning requires a significant amount of labeled data which is not easily obtained in the information security Industry. Figure 1 shows some of the widespread use cases of deep learning in InfoSec. Malware detection and network intrusion detection are two such areas where deep learning has shown significant improvements over the rule-based and classic machine learning-based solutions. Advent of SIEMs and active system logging has enabled InfoSec industry to embrace machine learning based approaches to detect security breaches and other malicious activities. We at Acalvio dabble with data to bring interesting use cases to aid the needs of the business. In fact, it has been ingrained in our genes to think and devise solutions based on advanced machine learning. In this blog we focused on how deep learning can be leveraged to address specific use cases that link security logs and deception technology. We present a white paper focusing on some of the Information Security (InfoSec) use cases that can be enabled through deep learning. We focus on the following: Introduce deep learning to InfoSec community with use cases they can relate to. Introduce deep learning architecture and nuances related to it. Introduce Feed Forward network (FFN) and anonymous traffic detection problem. How FFN can be leveraged to detect TOR traffic detection. Introduce convolutional neural network and how it can be used for InfoSec use cases. Introduce sequence labelling InfoSec tasks. How recurrent neural network and long short-term memory network can be used to detect C&C domains. We also look at the interesting problem of parameter optimization in DL systems. We use auto-ml framework explore and optimize the parameters. The white paper on detecting Tor traffic using deep learning can be downloaded from here: Detecting Anonymised Network Traffic using Deep Learning. Acalvio’s ShadowPlex lures attackers and malware alike to dynamically deployed deceptions with artificially induced vulnerabilities. It is an enticing prospect for attacker or malware to exfiltrate data or contact C&C from there. Our threat detection engines, can detect the data exfiltration and thus thwart the attack as well as capture more information about the adversary and the tools, techniques used by him. Please contact us for your queries regarding our solutions and products. References: [1] He, G., Yang, M., Luo, J. and Gu, X., “ Inferring Application Type Information from Tor Encrypted Traffic,” Advanced Cloud and Big Data (CBD), 2014 Second International Conference on (pp. 220-227), Nov. 2014. [2] Juarez, M., Afroz, S., Acar, G., Diaz, C. and Greenstadt, R., “A critical evaluation of website fingerprinting attacks,” Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (pp. 263-274), November 2014
Read More
Team Acalvio
|
June 13, 2018
Lateral Movement Technique by Hidden Cobra Threat Actor
US Cert recently issued notification regarding malicious cyber activity by the North Korean government [1] as Hidden Cobra.  There are two families of malware used by the North Korean Government. Remote Access Tool (RAT) known as Jonap A Server Message Block (SMB) worm called as Brambul worm. As per the report by US-Cert, threat actor have been using these malware since 2009 to target multiple victims globally and in United States,- including the media, aerospace, financial, and critical infrastructure sector. In this blog we share the technical details of the spreading techniques used by the Brambul worm and its detection by distributed deception platform. Brambul Worm The worm invokes multiple thread which then randomly generates the IP addresses for infection. Figure 1.0 Showing the code for random generation of IP address. Once the victim’s IP addresses, have been generated it  connects to \\IPC$ share, on the port 445 of the victim machine with Administrator as the username and fixed hardcoded passwords. Later down the malware code, it makes call to the WNetAddConnection2 API  to connect to a network resource and constructs the below command. “cmd.exe /q /c net share admin$=%%SystemRoot%% /GRANT:%s, FULL” It then make call to the service manager. OpenSCManagerA() with the victim machine machines on the network as the parameter.  StartSeviceA() is then called with the with the command as the parameter, will execute the command which will grant full permission on the remote machine.  Once the command has been executed, the code will make call to DeleteService() which will then delete the service. Once the full permission is granted on the remote machine, the worm is copied to the remote machine. Detection by Distributed Deception Platform The worm as such is not quite sophisticated and primarily relies on the brute force attempts. This will be successful only in weak environments. If the deception are deployed in a threat agnostic manner as discussed in the previous blog, network enumeration by the Brambul Worm will get detected by the distributed deception platform. Brute force condition will raise an alert of breach leading to the isolation of the infected endpoint. References: [1]  Hidden Cobra – North Korean Malicious  Cyber Activity. https://www.us-cert.gov/HIDDEN-COBRA-North-Korean-Malicious-Cyber-Activity [2] HIDDEN COBRA – Jonap Backdoor Trojan and Brambul SMB worm  https://www.us-cert.gov/ncas/alerts/TA18-149A
Read More
Team Acalvio
|
June 13, 2018
Lateral Movement Technique Employed by Hidden Cobra
US-Cert recently issued notification regarding malicious cyber activity by the North Korean government [1] Hidden Cobra. There are two families of malware used by the North Korean Government. Remote Access Tool (RAT) known as Jonap A Server Message Block (SMB) worm called as Brambul worm. As per the US-Certreport, Hdden Cobra has been using this malware since 2009 to target multiple victims globally and in the United States, including media, aerospace, financial industries, and critical infrastructure sectors. In this blog, we share the technical details and spreading techniques used by the Brambul worm. Thereafter, we discuss how it can be detected by distributed deception platform. Brambul Worm The worm invokes multiple threads which then randomly generates IP addresses for infection. Figure 1.0 Showing the code for random generation of IP address. Once the victim’s IP addresses have been generated it connects to \\IPC$ share, on the port 445 of the victim machine using Administrator as the username and fixed hardcoded passwords. Thereafter, the malware code makes a call to the WNetAddConnection2 API to connect to a network resource and constructs the below command. “cmd.exe /q /c net share admin$=%%SystemRoot%% /GRANT:%s, FULL” It then makes calls to the service manager. OpenSCManagerA() with the victim machine machines on the network as the parameter. StartSeviceA() then executes the command which grants full permission on the remote machine. Once the command has been executed, the code makes a call to DeleteService() which then deletes the service. Once the full permission is granted on the remote machine, the worm is copied to the remote machine. Detection by Distributed Deception Platform As such, the worm is not quite sophisticated and primarily relies on brute force attempts. This will be successful only in weak environments. If a Distributed Deception Platform is deployed in a threat agnostic manner network, enumeration by the Brambul Worm will get detected with very high confidence. [deployment of a distributed deception platform is discussed in a previous blog]. Brute force attacks on the Distributed Deception Platform leads to isolation of the end-point, thereby containing damage in a timely manner. References: [1] Hidden Cobra – North Korean Malicious Cyber Activity. [2] HIDDEN COBRA – Jonap Backdoor Trojan and Brambul SMB worm
Read More
Acalvio_New_Web_Blog_600x330_02
Team Acalvio
|
May 17, 2018
Detection of Breach Campaigns by using Distributed Deception
Today’s breaches are predominantly carried out in a series of sophisticated, multi-stage attacks. The stages involved in such an attack can best be described by a “Cyber Kill Chain”. This, as per MITRE ATT&CK Adversary Tactic Model [11] breaks down cyber intrusions into the steps shown in the following figure. As discussed in the previous blogs and the white paper deception solution deploys breadcrumbs and lures at the endpoint. These breadcrumbs and lures can be : Honey authentication values in the browsers such as adding honey authentication in “HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\IntelliForms\Storage2” for IE7, honey authentication values at “\Local\Google\Chrome\User Data\Default\Login Data” for Chrome etc.. Honey mapped drives Honey entries in the ARP cache Honey RDP links, Honey entries in the keychain Honey entries in the files such as password files under %APPDATA% folder. Honey entries in the active directory Honey connection from the Endpoint / Web Server to the services such as databases in the network, Honey email addresses in the address book of Outlook, Honey DNS server, Honey authentication values in the processes such as lsass. These end-point lures point to the honey services such as SMB, FTP, Databases in the subnet. Since the static breadcrumbs are interspersed with the real endpoint assets, there is always a possibility of legitimate assets getting used by a threat actor. This problem of legitimate assets getting used by the threat actor can be reduced by increasing the density of the breadcrumbs and lures at the endpoint. If there are “m” legitimate services and “n” honey services then if  { [ m / (n + m) ] <= 0.001} it will ensure the probability of accessing legitimate services remains less than equal to 0.1 %. In our previous blog, we analyzed six prevalent worms and malware. We discussed the precise breadcrumbs and lures that are required at the endpoint and honey services in the network and the conditions that will lead to their detection. In the following table 1.0, we have taken three breadcrumbs and listed the breaches that could have been diverted by using these breadcrumbs. The three breadcrumbs which we have considered are honey entries in the ARP cache, honey mapped drives and honey passwords in the browser and in the processes such as lsass. The reports of these breaches have been published publicly and are mentioned in the references. From the above table we can draw the following inferences: The deception platform gets triggered during the Credential Access, Discovery, Lateral Movement phases. Hence it complements other defenses which get triggered during the Initial Access, Execution, Persistence, Privilege Escalation, Defensive Evasion phases. These phases are as per the MITRE ATT&CK Matrix for the Enterprise. In some of the breaches, for example, Orangeworm [1] reported on April 23rd, 2018,  targeting hospitals, a deception platform would have been able to divert the multi-stage attack at multiple places by having honey entries in the ARP cache and also by having honey drives. These inferences make deception based architecture a recommended architecture to prevent modern-day breaches. References: [1] New Orangeworm attack group targets the healthcare sector in the U.S. , Europ, and Asia    https://www.symantec.com/blogs/threat-intelligence/orangeworm-targets-healthcare-us-europe-asia [2] APT 37 The overlooked North Korean Actor, https://www2.fireeye.com/rs/848-DID-242/images/rpt_APT37.pdf [3]  Bronze Butler Targets Japenese Enterproses https://www.secureworks.com/research/bronze-butler-targets-japanese-businesses [4] A window into Russian Cyber Espionage Operations ? https://www2.fireeye.com/rs/fireye/images/rpt-apt28.pdf [5]Cozy Duke, https://www.f-secure.com/documents/996508/1030745/CozyDuke [7]Operation Cleaver, https://www.cylance.com/content/dam/cylance/pdfs/reports/Cylance_Operation_Cleaver_Report.pdf [8] Muddying The Water : Targeted Attacks in The Middle East https://researchcenter.paloaltonetworks.com/2017/11/unit42-muddying-the-water-targeted-attacks-in-the-middle-east/ [9] Monsooon Campaign https://github.com/Cyb3rWard0g/ThreatHunter-Playbook/blob/master/adversary_attribution/MONSOON.md [10] Leviathan https://www.proofpoint.com/us/threat-insight/post/leviathan-espionage-actor-spearphishes-maritime-and-defense-targets [11] Mitre ATT&CK Adversary Model, https://attack.mitre.org/wiki/Main_Page [12] Stealth Falcon, https://citizenlab.ca/2016/05/stealth-falcon/
Read More
chess-flames-image1
Team Acalvio
|
March 1, 2018
A Game Between Adversary and Defender
The motivation for this blog is a question that has been circling in my head for a long time, and I have asked this question to many security analysts: Have they played a game with an adversary? or in other words – Have they engaged with an adversary? I got mixed responses. Many security analysts gave me an affirmative answer and shared their war stories when they have engaged with adversaries.  Specifically, when they faced attacks from nation-wide APTs, and the adversaries kept coming back to the network even after blocking them. On the other side, some security analysts ask me a question: Is it possible to play a game with an adversary? or watch the adversary continuously?   To answer this question, we need first to understand what it means to play a game or watch an adversary?.  Whenever we talk about a game, e.g., Chess, the players know about their actions, and strategies and they have complete visibility of each other’s actions. In the case of cybersecurity, the game is infinitely complex than Chess. The adversary’s actions are hidden, and the defender does not know about them. The defender does not even know if the adversary is present in the enterprise.   The defender can play a game with an adversary only if he can detect him continuously and able to determine that he is the same “returning” adversary. The returning adversary is the same one who was blocked earlier and has come back now. It can be typically established based on the similarity between TTP of various incidents. To monitor the adversary continuously while he is in the network, we need to have technology and infrastructure that can enable it.  The adversary can pick up any of the exploits and launch an attack from any attack surface.  Hence, to define a game or an engagement with the adversary, there is a need to define the adversaries activities in a framework. Mitre Attack matrix offers a framework to encapsulate the adversary tactics and techniques. Next, we need a way to detect the adversaries actions continuously. One can use a combination of high interaction deceptions, and AI techniques to provide a unique infrastructure to monitor the adversary activities continuously.  The adversary could be diverted or lead to a high interaction decoy using credentials, shares and other types of breadcrumbs.  The high interaction decoys could employ multiple cameras in the form of HIDs, Bro, and other tools that enable to continuously log the attacker’s activities. These logs can be further analyzed using various AI techniques to filter, summarise the identify the notable events and track the adversary activities. To summarise, watching/playing a game with an adversary has only been possible for a small percentage of defenders. However, a combination of deception and AI can lower the bar and enable more defenders to watch and engage with the adversaries.
Read More
Subscribe to Our Newsletter
Acalvio, the Ultimate Preemptive Cybersecurity Solution.