Search results

Like all modern cloud providers, Amazon adopts the shared responsibility model for cloud security. Amazon guarantees secure... AWS NACL best practices: How to combine security groups with network ACLs effectively Prof. Avishai Wool 2 min read Prof. Avishai Wool Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 8/28/23 Published Like all modern cloud providers, Amazon adopts the shared responsibility model for cloud security. Amazon guarantees secure infrastructure for Amazon Web Services, while AWS users are responsible for maintaining secure configurations. That requires using multiple AWS services and tools to manage traffic. You’ll need to develop a set of inbound rules for incoming connections between your Amazon Virtual Private Cloud (VPC) and all of its Elastic Compute (EC2) instances and the rest of the Internet. You’ll also need to manage outbound traffic with a series of outbound rules. Your Amazon VPC provides you with several tools to do this. The two most important ones are security groups and Network Access Control Lists (NACLs). Security groups are stateful firewalls that secure inbound traffic for individual EC2 instances. Network ACLs are stateless firewalls that secure inbound and outbound traffic for VPC subnets. Managing AWS VPC security requires configuring both of these tools appropriately for your unique security risk profile. This means planning your security architecture carefully to align it the rest of your security framework. For example, your firewall rules impact the way Amazon Identity Access Management (IAM) handles user permissions. Some (but not all) IAM features can be implemented at the network firewall layer of security. Before you can manage AWS network security effectively , you must familiarize yourself with how AWS security tools work and what sets them apart. Everything you need to know about security groups vs NACLs AWS security groups explained: Every AWS account has a single default security group assigned to the default VPC in every Region. It is configured to allow inbound traffic from network interfaces assigned to the same group, using any protocol and any port. It also allows all outbound traffic using any protocol and any port. Your default security group will also allow all outbound IPv6 traffic once your VPC is associated with an IPv6 CIDR block. You can’t delete the default security group, but you can create new security groups and assign them to AWS EC2 instances. Each security group can only contain up to 60 rules, but you can set up to 2500 security groups per Region. You can associate many different security groups to a single instance, potentially combining hundreds of rules. These are all allow rules that allow traffic to flow according the ports and protocols specified. For example, you might set up a rule that authorizes inbound traffic over IPv6 for linux SSH commands and sends it to a specific destination. This could be different from the destination you set for other TCP traffic. Security groups are stateful, which means that requests sent from your instance will be allowed to flow regardless of inbound traffic rules. Similarly, VPC security groups automatically responses to inbound traffic to flow out regardless of outbound rules. However, since security groups do not support deny rules, you can’t use them to block a specific IP address from connecting with your EC2 instance. Be aware that Amazon EC2 automatically blocks email traffic on port 25 by default – but this is not included as a specific rule in your default security group. AWS NACLs explained: Your VPC comes with a default NACL configured to automatically allow all inbound and outbound network traffic. Unlike security groups, NACLs filter traffic at the subnet level. That means that Network ACL rules apply to every EC2 instance in the subnet, allowing users to manage AWS resources more efficiently. Every subnet in your VPC must be associated with a Network ACL. Any single Network ACL can be associated with multiple subnets, but each subnet can only be assigned to one Network ACL at a time. Every rule has its own rule number, and Amazon evaluates rules in ascending order. The most important characteristic of NACL rules is that they can deny traffic. Amazon evaluates these rules when traffic enters or leaves the subnet – not while it moves within the subnet. You can access more granular data on data flows using VPC flow logs. Since Amazon evaluates NACL rules in ascending order, make sure that you place deny rules earlier in the table than rules that allow traffic to multiple ports. You will also have to create specific rules for IPv4 and IPv6 traffic – AWS treats these as two distinct types of traffic, so rules that apply to one do not automatically apply to the other. Once you start customizing NACLs, you will have to take into account the way they interact with other AWS services. For example, Elastic Load Balancing won’t work if your NACL contains a deny rule excluding traffic from 0.0.0.0/0 or the subnet’s CIDR. You should create specific inclusions for services like Elastic Load Balancing, AWS Lambda, and AWS CloudWatch. You may need to set up specific inclusions for third-party APIs, as well. You can create these inclusions by specifying ephemeral port ranges that correspond to the services you want to allow. For example, NAT gateways use ports 1024 to 65535. This is the same range covered by AWS Lambda functions, but it’s different than the range used by Windows operating systems. When creating these rules, remember that unlike security groups, NACLs are stateless. That means that when responses to allowed traffic are generated, those responses are subject to NACL rules. Misconfigured NACLs deny traffic responses that should be allowed, leading to errors, reduced visibility, and potential security vulnerabilities . How to configure and map NACL associations A major part of optimizing NACL architecture involves mapping the associations between security groups and NACLs. Ideally, you want to enforce a specific set of rules at the subnet level using NACLs, and a different set of instance-specific rules at the security group level. Keeping these rulesets separate will prevent you from setting inconsistent rules and accidentally causing unpredictable performance problems. The first step in mapping NACL associations is using the Amazon VPC console to find out which NACL is associated with a particular subnet. Since NACLs can be associated with multiple subnets, you will want to create a comprehensive list of every association and the rules they contain. To find out which NACL is associated with a subnet: Open the Amazon VPC console . Select Subnets in the navigation pane. Select the subnet you want to inspect. The Network ACL tab will display the ID of the ACL associated with that network, and the rules it contains. To find out which subnets are associated with a NACL: Open the Amazon VPC console . Select Network ACLS in the navigation pane. Click over to the column entitled Associated With. Select a Network ACL from the list. Look for Subnet associations on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL. Now that you know how the difference between security groups and NACLs and you can map the associations between your subnets and NACLs, you’re ready to implement some security best practices that will help you strengthen and simplify your network architecture. 5 best practices for AWS NACL management Pay close attention to default NACLs, especially at the beginning Since every VPC comes with a default NACL, many AWS users jump straight into configuring their VPC and creating subnets, leaving NACL configuration for later. The problem here is that every subnet associated with your VPC will inherit the default NACL. This allows all traffic to flow into and out of the network. Going back and building a working security policy framework will be difficult and complicated – especially if adjustments are still being made to your subnet-level architecture. Taking time to create custom NACLs and assign them to the appropriate subnets as you go will make it much easier to keep track of changes to your security posture as you modify your VPC moving forward. Implement a two-tiered system where NACLs and security groups complement one another Security groups and NACLs are designed to complement one another, yet not every AWS VPC user configures their security policies accordingly. Mapping out your assets can help you identify exactly what kind of rules need to be put in place, and may help you determine which tool is the best one for each particular case. For example, imagine you have a two-tiered web application with web servers in one security group and a database in another. You could establish inbound NACL rules that allow external connections to your web servers from anywhere in the world (enabling port 443 connections) while strictly limiting access to your database (by only allowing port 3306 connections for MySQL). Look out for ineffective, redundant, and misconfigured deny rules Amazon recommends placing deny rules first in the sequential list of rules that your NACL enforces. Since you’re likely to enforce multiple deny rules per NACL (and multiple NACLs throughout your VPC), you’ll want to pay close attention to the order of those rules, looking for conflicts and misconfigurations that will impact your security posture. Similarly, you should pay close attention to the way security group rules interact with your NACLs. Even misconfigurations that are harmless from a security perspective may end up impacting the performance of your instance, or causing other problems. Regularly reviewing your rules is a good way to prevent these mistakes from occurring. Limit outbound traffic to the required ports or port ranges When creating a new NACL, you have the ability to apply inbound or outbound restrictions. There may be cases where you want to set outbound rules that allow traffic from all ports. Be careful, though. This may introduce vulnerabilities into your security posture. It’s better to limit access to the required ports, or to specify the corresponding port range for outbound rules. This establishes the principle of least privilege to outbound traffic and limits the risk of unauthorized access that may occur at the subnet level. Test your security posture frequently and verify the results How do you know if your particular combination of security groups and NACLs is optimal? Testing your architecture is a vital step towards making sure you haven’t left out any glaring vulnerabilities. It also gives you a good opportunity to address misconfiguration risks. This doesn’t always mean actively running penetration tests with experienced red team consultants, although that’s a valuable way to ensure best-in-class security. It also means taking time to validate your rules by running small tests with an external device. Consider using AWS flow logs to trace the way your rules direct traffic and using that data to improve your work. How to diagnose security group rules and NACL rules with flow logs Flow logs allow you to verify whether your firewall rules follow security best practices effectively. You can follow data ingress and egress and observe how data interacts with your AWS security rule architecture at each step along the way. This gives you clear visibility into how efficient your route tables are, and may help you configure your internet gateways for optimal performance. Before you can use the Flow Log CLI, you will need to create an IAM role that includes a policy granting users the permission to create, configure, and delete flow logs. Flow logs are available at three distinct levels, each accessible through its own console: Network interfaces VPCs Subnets You can use the ping command from an external device to test the way your instance’s security group and NACLs interact. Your security group rules (which are stateful) will allow the response ping from your instance to go through. Your NACL rules (which are stateless) will not allow the outbound ping response to travel back to your device. You can look for this activity through a flow log query. Here is a quick tutorial on how to create a flow log query to check your AWS security policies. First you’ll need to create a flow log in the AWS CLI. This is an example of a flow log query that captures all rejected traffic for a specified network interface. It delivers the flow logs to a CloudWatch log group with permissions specified in the IAM role: aws ec2 create-flow-logs \ –resource-type NetworkInterface \ –resource-ids eni-1235b8ca123456789 \ –traffic-type ALL \ –log-group-name my-flow-logs \ –deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs Assuming your test pings represent the only traffic flowing between your external device and EC2 instance, you’ll get two records that look like this: 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027 1432917142 ACCEPT OK 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094 1432917142 REJECT OK To parse this data, you’ll need to familiarize yourself with flow log syntax. Default flow log records contain 14 arguments, although you can also expand custom queries to return more than double that number: Version tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4. Account-id tells you the account ID of the owner of the network interface that traffic is traveling through. The record may display as unknown if the network interface is part of an AWS service like a Network Load Balancer. Interface-id shows the unique ID of the network interface for the traffic currently under inspection. Srcaddr shows the source of incoming traffic, or the address of the network interface for outgoing traffic. In the case of IPv4 addresses for network interfaces, it is always its private IPv4 address. Dstaddr shows the destination of outgoing traffic, or the address of the network interface for incoming traffic. In the case of IPv4 addresses for network interfaces, it is always its private IPv4 address. Srcport is the source port for the traffic under inspection. Dstport is the destination port for the traffic under inspection. Protocol refers to the corresponding IANA traffic protocol number . Packets describes the number of packets transferred. Bytes describes the number of bytes transferred. Start shows the start time when the first data packet was received. This could be up to one minute after the network interface transmitted or received the packet. End shows the time when the last data packet was received. This can be up to one minutes after the network interface transmitted or received the data packet. Action describes what happened to the traffic under inspection: ACCEPT means that traffic was allowed to pass. REJECT means the traffic was blocked, typically by security groups or NACLs. Log-status confirms the status of the flow log: OK means data is logging normally. NODATA means no network traffic to or from the network interface was detected during the specified interval. SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors. Going back to the example above, the flow log output shows that a user sent a command from a device with the IP address 203.0.113.12 to the network interface’s private IP address, which is 172.31.16.139. The security group’s inbound rules allowed the ICMP traffic to travel through, producing an ACCEPT record. However, the NACL did not let the ping response go through, because it is stateless. This generated the REJECT record that followed immediately after. If you configure your NACL to permit output ICMP traffic and run this test again, the second flow log record will change to ACCEPT. azon Web Services (AWS) is one of the most popular options for organizations looking to migrate their business applications to the cloud. It’s easy to see why: AWS offers high capacity, scalable and cost-effective storage, and a flexible, shared responsibility approach to security. Essentially, AWS secures the infrastructure, and you secure whatever you run on that infrastructure. However, this model does throw up some challenges. What exactly do you have control over? How can you customize your AWS infrastructure so that it isn’t just secure today, but will continue delivering robust, easily managed security in the future? The basics: security groups AWS offers virtual firewalls to organizations, for filtering traffic that crosses their cloud network segments. The AWS firewalls are managed using a concept called Security Groups. These are the policies, or lists of security rules, applied to an instance – a virtualized computer in the AWS estate. AWS Security Groups are not identical to traditional firewalls, and they have some unique characteristics and functionality that you should be aware of, and we’ve discussed them in detail in video lesson 1: the fundamentals of AWS Security Groups , but the crucial points to be aware of are as follows. First, security groups do not deny traffic – that is, all the rules in security groups are positive, and allow traffic. Second, while security group rules can be set to specify a traffic source, or a destination, they cannot specify both on the same rule. This is because AWS always sets the unspecified side (source or destination) as the instance to which the group is applied. Finally, single security groups can be applied to multiple instances, or multiple security groups can be applied to a single instance: AWS is very flexible. This flexibility is one of the unique benefits of AWS, allowing organizations to build bespoke security policies across different functions and even operating systems, mixing and matching them to suit their needs. Adding Network ACLs into the mix To further enhance and enrich its security filtering capabilities AWS also offers a feature called Network Access Control Lists (NACLs). Like security groups, each NACL is a list of rules, but there are two important differences between NACLs and security groups. The first difference is that NACLs are not directly tied to instances, but are tied with the subnet within your AWS virtual private cloud that contains the relevant instance. This means that the rules in a NACL apply to all of the instances within the subnet, in addition to all the rules from the security groups. So a specific instance inherits all the rules from the security groups associated with it, plus the rules associated with a NACL which is optionally associated with a subnet containing that instance. As a result NACLs have a broader reach, and affect more instances than a security group does. The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules – for example to block traffic from a particular set of IP addresses which are known to be compromised. The ability to write ‘deny’ actions is a crucial part of NACL functionality. It’s all about the order As a consequence, when you have the ability to write both ‘allow’ rules and ‘deny’ rules, the order of the rules now becomes important. If you switch the order of the rules between a ‘deny’ and ‘allow’ rule, then you’re potentially changing your filtering policy quite dramatically. To manage this, AWS uses the concept of a ‘rule number’ within each NACL. By specifying the rule number, you can identify the correct order of the rules for your needs. You can choose which traffic you deny at the outset, and which you then actively allow. As such, with NACLs you can manage security tasks in a way that you cannot do with security groups alone. However, we did point out earlier that an instance inherits security rules from both the security groups, and from the NACLs – so how do these interact? The order by which rules are evaluated is this; For inbound traffic, AWS’s infrastructure first assesses the NACL rules. If traffic gets through the NACL, then all the security groups that are associated with that specific instance are evaluated, and the order in which this happens within and among the security groups is unimportant because they are all ‘allow’ rules. For outbound traffic, this order is reversed: the traffic is first evaluated against the security groups, and then finally against the NACL that is associated with the relevant subnet. You can see me explain this topic in person in my new whiteboard video: Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Update : Next two parts of the analysis are available here and here . As earlier reported by FireEye, the actors behind a global... Cloud Security Sunburst Backdoor: A Deeper Look Into The SolarWinds’ Supply Chain Malware Rony Moshkovich 2 min read Rony Moshkovich Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 12/15/20 Published Update : Next two parts of the analysis are available here and here . As earlier reported by FireEye, the actors behind a global intrusion campaign have managed to trojanise SolarWinds Orion business software updates in order to distribute malware. The original FireEye write-up already provides a detailed description of this malware. Nevertheless, as the malicious update SolarWinds-Core-v2019.4.5220-Hotfix5.msp was still available for download for hours since the FireEye’s post, it makes sense to have another look into the details of its operation. The purpose of this write-up is to provide new information, not covered in the original write-up. Any overlaps with the original description provided by FireEye are not intentional. For start, the malicious component SolarWinds.Orion.Core.BusinessLayer.dll inside the MSP package is a non-obfuscated .NET assembly. It can easily be reconstructed with a .NET disassembler, such as ILSpy , and then fully reproduced in C# code, using Microsoft Visual Studio. Once reproduced, it can be debugged to better understand how it works. In a nutshell, the malicious DLL is a backdoor. It is loaded into the address space of the legitimate SolarWinds Orion process SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe . The critical strings inside the backdoor’s class SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer are encoded with the DeflateStream Class of the .NET’s System.IO.Compression library, coupled with the standard base64 encoder. Initialisation Once loaded, the malware checks if its assembly file was created earlier than 12, 13, or 14 days ago. The exact number of hours it checks is a random number from 288 to 336. Next, it reads the application settings value ReportWatcherRetry . This value keeps the reporting status, and may be set to one of the states: New (4) Truncate (3) Append (5) When the malware runs the first time, its reporting status variable ReportWatcherRetry is set to New (4) . The reporting status is an internal state that drives the logic. For example, if the reporting status is set to Truncate , the malware will stop operating by first disabling its networking communications, and then disabling other security tools and antivirus products. In order to stay silent, the malware periodically falls asleep for a random period of time that varies between 30 minutes and 2 hours. At the start, the malware obtains the computer’s domain name . If the domain name is empty, the malware quits. It then generates a 8-byte User ID, which is derived from the system footprint. In particular, it is generated from MD5 hash of a string that consists from the 3 fields: the first or default operational (can transmit data packets) network interface’s physical address computer’s domain name UUID created by Windows during installation (machine’s unique ID) Even though it looks random, the User ID stays permanent as long as networking configuration and the Windows installation stay the same. Domain Generation Algorithm The malware relies on its own CryptoHelper class to generate a domain name. This class is instantiated from the 8-byte User ID and the computer’s domain name, encoded with a substitution table: “rq3gsalt6u1iyfzop572d49bnx8cvmkewhj” . For example, if the original domain name is “ domain “, its encoded form will look like: “ n2huov “. To generate a new domain, the malware first attempts to resolve domain name “ api.solarwinds.com “. If it fails to resolve it, it quits. The first part of the newly generated domain name is a random string, produced from the 8-byte User ID, a random seed value, and encoded with a custom base64 alphabet “ph2eifo3n5utg1j8d94qrvbmk0sal76c” . Because it is generated from a random seed value, the first part of the newly generated domain name is random. For example, it may look like “ fivu4vjamve5vfrt ” or “ k1sdhtslulgqoagy “. To produce the domain name, this string is then appended with the earlier encoded domain name (such as “ n2huov “) and a random string, selected from the following list: .appsync-api.eu-west-1[.]avsvmcloud[.]com .appsync-api.us-west-2[.]avsvmcloud[.]com .appsync-api.us-east-1[.]avsvmcloud[.]com .appsync-api.us-east-2[.]avsvmcloud[.]com For example, the final domain name may look like: fivu4vjamve5vfrtn2huov[.]appsync-api.us-west-2[.]avsvmcloud[.]com or k1sdhtslulgqoagyn2huov[.]appsync-api.us-east-1[.]avsvmcloud[.]com Next, the domain name is resolved to an IP address, or to a list of IP addresses. For example, it may resolve to 20.140.0.1 . The resolved domain name will be returned into IPAddress structure that will contain an AddressFamily field – a special field that specifies the addressing scheme. If the host name returned in the IPAddress structure is different to the queried domain name, the returned host name will be used as a C2 host name for the backdoor. Otherwise, the malware will check if the resolved IP address matches one of the patterns below, in order to return an ‘address family’: IP Address Subnet Mask ‘Address Family’ 10.0.0.0 255.0.0.0 Atm 172.16.0.0 255.240.0.0 Atm 192.168.0.0 255.255.0.0 Atm 224.0.0.0 240.0.0.0 Atm fc00:: fe00:: Atm fec0:: ffc0:: Atm ff00:: ff00:: Atm 41.84.159.0 255.255.255.0 Ipx 74.114.24.0 255.255.248.0 Ipx 154.118.140.0 255.255.255.0 Ipx 217.163.7.0 255.255.255.0 Ipx 20.140.0.0 255.254.0.0 ImpLink 96.31.172.0 255.255.255.0 ImpLink 131.228.12.0 255.255.252.0 ImpLink 144.86.226.0 255.255.255.0 ImpLink 8.18.144.0 255.255.254.0 NetBios 18.130.0.0 255.255.0.0 NetBios 71.152.53.0 255.255.255.0 NetBios 99.79.0.0 255.255.0.0 NetBios 87.238.80.0 255.255.248.0 NetBios 199.201.117.0 255.255.255.0 NetBios 184.72.0.0 255.254.0.0 NetBios For example, if the queried domain resolves to 20.140.0.1 , it will match the entry in the table 20.140.0.0 , for which the returned ‘address family’ will be ImpLink . The returned ‘address family’ invokes an additional logic in the malware. Disabling Security Tools and Antivirus Products If the returned ‘address family’ is ImpLink or Atm , the malware will enumerate all processes and for each process, it will check if its name matches one of the pre-defined hashes. Next, it repeats this processed for services and for the drivers installed in the system. If a process name or a full path of an installed driver matches one of the pre-defined hashes, the malware will disable it. For hashing, the malware relies on Fowler–Noll–Vo algorithm. For example, the core process of Windows Defender is MsMpEng.exe . The hash value of “ MsMpEng ” string is 5183687599225757871 . This value is specifically enlisted the malware’s source under a variable name timeStamps : timeStamps = new ulong[1] { 5183687599225757871uL } The service name of Windows Defender is windefend – the hash of this string ( 917638920165491138 ) is also present in the malware body. As a result, the malicioius DLL will attempt to stop the Windows Defender service. In order to disable various security tools and antivirus products, the malware first grants itself SeRestorePrivilege and SeTakeOwnershipPrivilege privileges, using the native AdjustTokenPrivileges() API. With these privileges enabled, the malware takes ownership of the service registry keys it intends to manipulate. The new owner of the keys is first attempted to be explicitly set to Administrator account. If such account is not present, the malware enumerates all user accounts, looking for a SID that represents the administrator account. The malware uses Windows Management Instrumentation query “ Select * From Win32_UserAccount ” to obtain the list of all users. For each enumerated user, it makes sure the account is local and then, when it obtains its SID, it makes sure the SID begins with S-1-5- and ends with -500 in order to locate the local administrator account. Once such account is found, it is used as a new owner for the registry keys, responsible for manipulation of the services of various security tools and antivirus products. With the new ownership set, the malware then disables these services by setting their Start value to 4 (Disabled): registryKey2.SetValue(“Start”), 4, RegistryValueKind.DWord); HTTP Backdoor If the returned ‘address family’ for the resolved domain name is NetBios , as specified in the lookup table above, the malware will initialise its HttpHelper class, which implements an HTTP backdoor. The backdoor commands are covered in the FireEye write-up, so let’s check only a couple of commands to see what output they produce. One of the backdoor commands is CollectSystemDescription . As its name suggests, it collects system information. By running the code reconstructed from the malware, here is an actual example of the data collected by the backdoor and delivered to the attacker’s C2 with a separate backdoor command UploadSystemDescription : 1. %DOMAIN_NAME% 2. S-1-5-21-298510922-2159258926-905146427 3. DESKTOP-VL39FPO 4. UserName 5. [E] Microsoft Windows NT 6.2.9200.0 6.2.9200.0 64 6. C:\WINDOWS\system32 7. 0 8. %PROXY_SERVER% Description: Killer Wireless-n/a/ac 1535 Wireless Network Adapter #2 MACAddress: 9C:B6:D0:F6:FF:5D DHCPEnabled: True DHCPServer: 192.168.20.1 DNSHostName: DESKTOP-VL39FPO DNSDomainSuffixSearchOrder: Home DNSServerSearchOrder: 8.8.8.8, 192.168.20.1 IPAddress: 192.168.20.30, fe80::8412:d7a8:57b9:5886 IPSubnet: 255.255.255.0, 64 DefaultIPGateway: 192.168.20.1, fe80::1af1:45ff:feec:a8eb NOTE: Field #7 specifies the number of days (0) since the last system reboot. GetProcessByDescription command will build a list of processes running on a system. This command accepts an optional argument, which is one of the custom process properties enlisted here . If the optional argument is not specified, the backdoor builds a process list that looks like: [ 1720] svchost [ 8184] chrome [ 4732] svchost If the optional argument is specified, the backdoor builds a process list that includes the specified process property in addition to parent process ID, username and domain for the process owner. For example, if the optional argument is specified as “ ExecutablePath “, the GetProcessByDescription command may return a list similar to: [ 3656] sihost.exe C:\WINDOWS\system32\sihost.exe 1720 DESKTOP-VL39FPO\UserName [ 3824] svchost.exe C:\WINDOWS\system32\svchost.exe 992 DESKTOP-VL39FPO\UserName [ 9428] chrome.exe C:\Program Files (x86)\Google\Chrome\Application\chrome.exe 4600 DESKTOP-VL39FPO\UserName Other backdoor commands enable deployment of the 2nd stage malware. For example, the WriteFile command will save the file: using (FileStream fileStream = new FileStream(path, FileMode.Append, FileAccess.Write)) { fileStream.Write(array, 0, array.Length); } The downloaded 2nd stage malware can then the executed with RunTask command: using (Process process = new Process()) { process.StartInfo = new ProcessStartInfo(fileName, arguments) { CreateNoWindow = false, UseShellExecute = false }; if (process.Start()) … Alternatively, it can be configured to be executed with the system restart, using registry manipulation commands, such as SetRegistryValue . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

SaaS SLA Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Product Marketing Manager AlgoSec Cloud Navigating Compliance in the Cloud Iris Stein 2 min read Iris Stein Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/29/25 Published Cloud adoption isn't just soaring; it's practically stratospheric. Businesses of all sizes are leveraging the agility, scalability, and innovation that cloud environments offer. Yet, hand-in-hand with this incredible growth comes an often-overlooked challenge: the increasing complexities of maintaining compliance. Whether your organization grapples with industry-specific regulations like HIPAA for healthcare, PCI DSS for payment processing, SOC 2 for service organizations, or simply adheres to stringent internal governance policies, navigating the ever-shifting landscape of cloud compliance can feel incredibly daunting. It's akin to staring at a giant, knotted ball of spaghetti, unsure where to even begin untangling. But here’s the good news: while it demands attention and a strategic approach, staying compliant in the cloud is far from an impossible feat. This article aims to be your friendly guide through the compliance labyrinth, offering practical insights and key considerations to help you maintain order and assurance in your cloud environments. The foundation: Understanding the Shared Responsibility Model Before you even think about specific regulations, you must grasp the Shared Responsibility Model . This is the bedrock of cloud compliance, and misunderstanding it is a common pitfall that can lead to critical security and compliance gaps. In essence, your cloud provider (AWS, Azure, Google Cloud, etc.) is responsible for the security of the cloud – that means the underlying infrastructure, the physical security of data centers, the global network, and the hypervisors. However, you are responsible for the security in the cloud . This includes your data, your configurations, network traffic protection, identity and access management, and the applications you deploy. Think of it like a house: the cloud provider builds and secures the house (foundation, walls, roof), but you’re responsible for what you put inside it, how you lock the doors and windows, and who you let in. A clear understanding of this division is paramount for effective cloud security and compliance. Simplify to conquer: Centralize your compliance efforts Imagine trying to enforce different rules for different teams using separate playbooks – it's inefficient and riddled with potential for error. The same applies to cloud compliance, especially in multi-cloud environments. Juggling disparate compliance requirements across multiple cloud providers manually is not just time-consuming; it's a recipe for errors, missed deadlines, and a constant state of anxiety. The solution? Aim for a unified, centralized approach to policy enforcement and auditing across your entire multi-cloud footprint. This means establishing consistent security policies and compliance controls that can be applied and monitored seamlessly, regardless of which cloud platform your assets reside on. A unified strategy streamlines management, reduces complexity, and significantly lowers the risk of non-compliance. The power of automation: Your compliance superpower Manual compliance checks are, to put it mildly, an Achilles' heel in today's dynamic cloud environments. They are incredibly time-consuming, prone to human error, and simply cannot keep pace with the continuous changes in cloud configurations and evolving threats. This is where automation becomes your most potent compliance superpower. Leveraging automation for continuous monitoring of configurations, access controls, and network flows ensures ongoing adherence to compliance standards. Automated tools can flag deviations from policies in real-time, identify misconfigurations before they become vulnerabilities, and provide instant insights into your compliance posture. Think of it as having an always-on, hyper-vigilant auditor embedded directly within your cloud infrastructure. It frees up your security teams to focus on more strategic initiatives, rather than endless manual checks. Prove it: Maintain comprehensive audit trails Compliance isn't just about being compliant; it's about proving you're compliant. When an auditor comes knocking – and they will – you need to provide clear, irrefutable, and easily accessible evidence of your compliance posture. This means maintaining comprehensive, immutable audit trails . Ensure that all security events, configuration changes, network access attempts, and policy modifications are meticulously logged and retained. These logs serve as your digital paper trail, demonstrating due diligence and adherence to regulatory requirements. The ability to quickly retrieve specific audit data is critical during assessments, turning what could be a stressful scramble into a smooth, evidence-based conversation. The dynamic duo: Regular review and adaptation Cloud environments are not static. Regulations evolve, new services emerge, and your own business needs change. Therefore, compliance in the cloud is never a "set it and forget it" task. It requires a dynamic approach: regular review and adaptation . Implement a robust process for periodically reviewing your compliance controls. Are they still relevant? Are there new regulations or updates you need to account for? Are your existing controls still effective against emerging threats? Adapt your policies and controls as needed to ensure continuous alignment with both external regulatory demands and your internal security posture. This proactive stance keeps you ahead of potential issues rather than constantly playing catch-up. Simplify Your Journey with the Right Tools Ultimately, staying compliant in the cloud boils down to three core pillars: clear visibility into your cloud environment, consistent and automated policy enforcement, and the demonstrable ability to prove adherence. This is where specialized tools can be invaluable. Solutions like AlgoSec Cloud Enterprise can truly be your trusted co-pilot in this intricate journey. It's designed to help you discover all your cloud assets across multiple providers, proactively identify compliance risks and misconfigurations, and automate policy enforcement. By providing a unified view and control plane, it gives you the confidence that your multi-cloud environment not only meets but also continuously maintains the strictest regulatory requirements. Don't let the complexities of cloud compliance slow your innovation or introduce unnecessary risk. Embrace strategic approaches, leverage automation, and choose the right partners to keep those clouds compliant and your business secure. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Learn best practices for mastering compliance automation for network security Webinars 5 Keys to Success: Automating compliance for network security In a landscape where technological progression is rapidly advancing every day, network security has become a crucial factor in the success of businesses. Keeping sensitive data secure is no longer just an option, it’s a necessity. But, with security issues constantly on the rise, maintaining compliance can be an overwhelming and time-consuming task for IT professionals. In this webinar, we cover automating compliance for network security as a key component for ensuring business. Join us to see why this is a crucial aspect of ensuring business success in today’s digital landscape. June 13, 2023 Tsippi Dach Director of marketing communications Asher Benbenisty Director of product marketing Relevant resources Cisco Regulatory Compliance Watch Video Automated Security Policy Changes for Speed and Compliance Keep Reading [Panel] How financial institutions can achieve network security and compliance Keep Reading Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Avishai Wool, CTO and co-founder of AlgoSec, looks at how organizations can implement and manage SDN-enabled micro-segmentation... Micro-segmentation Building a Blueprint for a Successful Micro-segmentation Implementation Prof. Avishai Wool 2 min read Prof. Avishai Wool Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/22/20 Published Avishai Wool, CTO and co-founder of AlgoSec, looks at how organizations can implement and manage SDN-enabled micro-segmentation strategies Micro-segmentation is regarded as one of the most effective methods to reduce an organization’s attack surface, and a lack of it has often been cited as a contributing factor in some of the largest data breaches and ransomware attacks. One of the key reasons why enterprises have been slow to embrace it is because it can be complex and costly to implement – especially in traditional on-premise networks and data centers. In these, creating internal zones usually means installing extra firewalls, changing routing, and even adding cabling to police the traffic flows between zones, and having to manage the additional filtering policies manually. However, as many organizations are moving to virtualized data centers using Software-Defined Networking (SDN), some of these cost and complexity barriers are lifted. In SDN-based data centers the networking fabric has built-in filtering capabilities, making internal network segmentation much more accessible without having to add new hardware. SDN’s flexibility enables advanced, granular zoning: In principle, data center networks can be divided into hundreds, or even thousands, of microsegments. This offers levels of security that would previously have been impossible – or at least prohibitively expensive – to implement in traditional data centers. However, capitalizing on the potential of micro-segmentation in virtualized data centers does not eliminate all the challenges. It still requires the organization to deploy a filtering policy that the micro-segmented fabric will enforce, and writing this a policy is the first, and largest, hurdle that must be cleared. The requirements from a micro-segmentation policy A correct micro-segmentation filtering policy has three high-level requirements: It allows all business traffic – The last thing you want is to write a micro-segmented policy and have it block necessary business communication, causing applications to stop functioning. It allows nothing else – By default, all other traffic should be denied. It is future-proof – ‘More of the same’ changes in the network environment shouldn’t break rules. If you write your policies too narrowly, when something in the network changes, such as a new server or application, something will stop working. Write with scalability in mind. A micro-segmentation blueprint Now that you know what you are aiming for, how can you actually achieve it? First of all, your organization needs to know what your traffic flows are – what is the traffic that should be allowed. To get this information, you can perform a ‘discovery’ process. Only once you have this information, can you then establish where to place the borders between the microsegments in the data center and how to devise and manage the security policies for each of the segments in their network environment. I welcome you to download AlgoSec’s new eBook , where we explain in detail how to implement and manage micro-segmentation. AlgoSec Enables Micro-segmentation The AlgoSec Security Management Suite (ASMS) employs the power of automation to make it easy to define and enforce your micro-segmentation strategy inside the data center, ensure that it does not block critical business services, and meet compliance requirements. AlgoSec supports micro-segmentation by: Providing application discovery based on netflow information Identifying unprotected network flows that do not cross any firewall and are not filtered for an application Automatically identifying changes that will violate the micro-segmentation strategy Automatically implementing network security changes Automatically validating changes The bottom line is that implementing an effective network micro-segmentation strategy is now possible. It requires careful planning and implementation, but when carried out following a proper blueprint and with the automation capabilities of the AlgoSec Security Management Suite, it provides you with stronger security without sacrificing any business agility. Find out more about how micro-segmentation can help you boost your security posture, or request your personal demo . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Building trust in automation WhitePaper Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Partner solution brief AlgoSec and Check Point Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Level Up Your Security Game: Time for a Mindset Reset! Hey everyone, and welcome! If you're involved in keeping your organization safe online these days, you're in the right place. For years, security felt like building a super strong castle with thick walls and a deep moat, hoping the bad guys would just stay outside. But let's be real, in our multi-cloud world, that castle is starting to look a little... outdated. Think about it: your apps and data aren't neatly tucked away in one place... 5 mindset shifts security teams must adopt to master multi-cloud security Iris Stein 2 min read Iris Stein Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 4/9/25 Published Level Up Your Security Game: Time for a Mindset Reset! Hey everyone, and welcome! If you're involved in keeping your organization safe online these days, you're in the right place. For years, security felt like building a super strong castle with thick walls and a deep moat, hoping the bad guys would just stay outside. But let's be real, in our multi-cloud world, that castle is starting to look a little... outdated. Think about it: your apps and data aren't neatly tucked away in one place anymore. They're bouncing around on AWS, Azure, GCP, all sorts of platforms – practically everywhere! Trying to handle that with old-school security is like trying to catch smoke with a fishing net. Not gonna work, right? That's why we're chatting today. Gal Yosef, Head of Product Management in the U.S., gets it. He's helped us dive into some crucial mindset shifts – basically, new ways of thinking – that are essential for navigating the craziness of modern security. We gotta ditch the old ways and get ready to be more agile, work together better, and ultimately, be way more effective. Mindset Shift #1: From "Our Stuff is Safe Inside This Box" to "Trust Nothing, Verify Everything" Remember the good old days? We built a perimeter – firewalls, VPNs – thinking that everything inside was safe and sound (danger!). Security was all about guarding that edge. The Problem: Well, guess what? That world is gone! Multi-cloud environments have totally shattered that perimeter. Trying to just secure the network edge leaves your real treasures – your applications, users, and data – vulnerable as they roam across different clouds. It's like locking the front door but leaving all the windows wide open! The New Way: Distributed Trust. Security needs to follow your assets, wherever they go. Instead of just focusing on the infrastructure (the pipes and wires), we need to embrace Zero-Trust principles . Think of it like this: never assume anyone or anything is trustworthy, even if they're "inside." We need identity-based, adaptive security policies that constantly validate trust, rather than just assuming it based on location. Security becomes built into applications and workloads, not just bolted onto the network. Think of it this way: Instead of one big, guarded gate, you have individual, smart locks on every valuable asset. You're constantly checking who's accessing what, no matter where they are. It's like having a personal bodyguard for each of your important things, always making sure they have the right ID. Mindset Shift #2: From "My Team Handles Network Security, Their Team Handles Cloud Security" to "Let's All Be Security Buddies!" Ever feel like your network security team speaks a different language than your cloud security team? You're not alone! Traditionally, these have been separate worlds, with network teams focused on firewalls and cloud teams on security groups. The Problem: These separate silos are a recipe for confusion and fragmented security policies. Attackers? They love this! It's like having cracks in your armor. They aren't always going to bash down the front door; they're often slipping through the gaps created by this lack of communication. The New Way: Cross-functional collaboration. We need to tear down those walls! Network and cloud security teams need to work together, speaking a shared security language. Unified visibility and consistent policies across all your environments are key. Think of it like a superhero team – everyone has their own skills, but they work together seamlessly to fight the bad guys. Regular communication, shared tools, and a common understanding of the risks are crucial. Mindset Shift #3: From "Reacting When Something Breaks" to "Always Watching and Fixing Things Before They Do" Remember the old days of waiting for an alert to pop up saying something was wrong? That's like waiting for your car to break down before you even think about checking the oil. Not the smartest move, right? The Problem: In the fast-paced world of the cloud, waiting for things to go wrong is a recipe for disaster. Attacks can happen super quickly, and by the time you react, the damage might already be done. Plus, manually checking everything all the time? Forget about it – it's just not scalable when you've got stuff spread across multiple clouds. The New Way: Continuous & Automated Enforcement. We need to shift to a mindset of constant monitoring and automated security actions. Think of it like having a security system that's always on, always learning, and can automatically respond to threats in real-time. This means using tools and processes that continuously check for vulnerabilities, enforce security policies automatically, and even predict potential problems before they happen. It's like having a proactive security guard who not only watches for trouble but can also automatically lock doors and sound alarms the moment something looks fishy. Mindset Shift #4: From "Locking Everything Down Tight" to "Finding the Right Balance with Flexible Rules" We used to think the best security was the strictest security – lock everything down, say "no" to everything. But let's be honest, that can make it super hard for people to actually do their jobs! It's like putting so many locks on a door that nobody can actually get through it. The Problem: Overly restrictive security can stifle innovation and slow things down. Developers can get frustrated, and the business can't move as quickly as it needs to. Plus, sometimes those super strict rules can even create workarounds that actually make things less secure in the long run. The New Way: Flexible Guardrails. We need to move towards security that provides clear boundaries (the "guardrails") but also allows for agility and flexibility. Think of it like setting clear traffic laws – you know what's allowed and what's not, but you can still drive where you need to go. This means defining security policies that are adaptable to different cloud environments and business needs. It's about enabling secure innovation, not blocking it. We need to find that sweet spot where security empowers the business instead of hindering it. Mindset Shift #5: From "Security is a Cost Center" to "Security is a Business Enabler" Sometimes, security gets seen as just an expense, something we have to do but doesn't really add value. It's like thinking of insurance as just another bill. The Problem: When security is viewed as just a cost, it often gets underfunded or seen as a roadblock. This can lead to cutting corners and ultimately increasing risk. It's like trying to save money by neglecting the brakes on your car – it might seem cheaper in the short term, but it can have disastrous consequences later. The New Way: Security as a Business Enabler. We need to flip this thinking! Strong security isn't just about preventing bad things from happening; it's about building trust with customers, enabling new business opportunities, and ensuring the long-term resilience of the organization. Think of it like a strong foundation for a building – without it, you can't build anything lasting. By building security into our processes and products from the start, we can actually accelerate innovation and gain a competitive advantage. It's about showing our customers that we take their data seriously and that they can trust us. Wrapping Up: Moving to a multi-cloud world is exciting, but it definitely throws some curveballs at how we think about security. By adopting these five new mindsets, we can ditch the outdated castle mentality and build a more agile, collaborative, and ultimately more secure future for our organizations. It's not about being perfect overnight, but about starting to shift our thinking and embracing these new approaches. So, let's level up our security game together! Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Security Policy Management with Professor Wool Micro-Segmentation Implementing a micro-segmentation strategy in the data center blocks lateral movement and helps protect the organization from cyberthreats. Watch this whiteboard video series on micro-segmentation and learn why and how to segment the data center, how to future-proof your policies and about the ongoing maintenance of a micro-segmented data center. Lesson 1 In this video, Prof. Wool introduces micro-segmentation: reasons for segmenting the data center, challenges, required steps when deploying a micro-segmentation strategy, and how to future-proof your policies. Introduction to Micro-segmentation Watch Lesson 2 Watch Prof. Wool as he shares tips on how to prepare for network segmentation by identifying the segment borders. Micro-segmentation – Mapping Existing Applications Watch Lesson 3 Watch this Prof. Wool video to learn how to define logical segments within a micro-segmentation project. Micro-segmentation – Defining Logical Segments Watch Lesson 4 In this video, Prof. Wool demonstrates how to generate a filtering policy during a micro-segmentation project. Micro-segmentation – Generating a Filtering Policy Watch Lesson 5 Watch this Prof. Wool video to learn about the ongoing maintenance of your data center upon completion of a micro-segmentation project. Micro-segmentation Ongoing Maintenance Watch Have a Question for Professor Wool? Ask him now Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Robert Bigman is uniquely equipped to share actionable tips for hardening your network security against vulnerabilities Don’t miss this opportunity to learn the latest threats and how to handle them Webinars Measures that actually DO reduce your hacking risk Learn from the best how to defeat hackers and ransomware As incidents of ransomware attacks become more common, the time has come to learn from the best how to defeat hackers. Join us as Robert Bigman, the former CISO of the CIA, presents his webinar Measures that Actually do Reduce your Hacking Risk. Robert Bigman is uniquely equipped to share actionable tips for hardening your network security against vulnerabilities. Don’t miss this opportunity to learn the latest threats and how to handle them. April 20, 2022 Robert Bigman Consultant; Former CISO of the CIA Relevant resources Ensuring critical applications stay available and secure while shifting to remote work Keep Reading Reducing risk of ransomware attacks - back to basics Keep Reading Ransomware Attack: Best practices to help organizations proactively prevent, contain and Keep Reading Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Previous Part of the analysis is available here. Next Part of the analysis is available here. Update from 19 December 2020: ‍Prevasio... Cloud Security Sunburst Backdoor, Part II: DGA & The List of Victims Rony Moshkovich 2 min read Rony Moshkovich Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 12/17/20 Published Previous Part of the analysis is available here . Next Part of the analysis is available here . Update from 19 December 2020: Prevasio would like to thank Zetalytics for providing us with an updated (larger) list of passive (historic) DNS queries for the domains generated by the malware. As described in the first part of our analysis, the DGA (Domain Generation Algorithm) of the Sunburst backdoor produces a domain name that may look like: fivu4vjamve5vfrtn2huov[.]appsync-api.us-west-2[.]avsvmcloud[.]com The first part of the domain name (before the first dot) consists of a 16-character random string, appended with an encoded computer’s domain name. This is the domain in which the local computer is registered. From the example string above, we can conclude that the encoded computer’s domain starts from the 17th character and up until the dot (highlighted in yellow): fivu4vjamve5vfrt n2huov In order to encode a local computer’s domain name, the malware uses one of 2 simple methods: Method 1 : a substitution table, if the domain name consists of small letters, digits, or special characters ‘-‘, ‘_’, ‘.’ Method 2 : base64 with a custom alphabet, in case of capital letters present in the domain name Method 1 In our example, the encoded domain name is “n2huov” . As it does not have any capital letters, the malware encodes it with a substitution table “rq3gsalt6u1iyfzop572d49bnx8cvmkewhj” . For each character in the domain name, the encoder replaces it with a character located in the substitution table four characters right from the original character. In order to decode the name back, all we have to do is to replace each encoded character with another character, located in the substitution table four characters left from the original character. To illustrate this method, imagine that the original substitution table is printed on a paper strip and then covered with a card with 6 perforated windows. Above each window, there is a sticker note with a number on it, to reflect the order of characters in the word “n2huov” , where ‘n’ is #1, ‘2’ is #2, ‘h’ is #3 and so on: Once the paper strip is pulled by 4 characters right, the perforated windows will reveal a different word underneath the card: “domain” , where ‘d’ is #1, ‘o’ is #2, ‘m’ is #3, etc.: A special case is reserved for such characters as ‘0’ , ‘-‘ , ‘_’ , ‘.’ . These characters are encoded with ‘0’ , followed with a character from the substitution table. An index of that character in the substitution table, divided by 4, provides an index within the string “0_-.” . The following snippet in C# illustrates how an encoded string can be decoded: static string decode_domain( string s) { string table = "rq3gsalt6u1iyfzop572d49bnx8cvmkewhj" ; string result = "" ; for ( int i = 0 ; i < s.Length; i++) { if (s[i] != '0' ) { result += table[(table.IndexOf(s[i]) + table.Length - 4 ) % table.Length]; } else { if (i < s.Length - 1 ) { if (table.Contains(s[i + 1 ])) { result += "0_-." [table.IndexOf(s[i + 1 ]) % 4 ]; } else { break ; } } i++; } } return result; } Method 2 This method is a standard base64 encoder with a custom alphabet “ph2eifo3n5utg1j8d94qrvbmk0sal76c” . Here is a snippet in C# that provides a decoder: public static string FromBase32String( string str) { string table = "ph2eifo3n5utg1j8d94qrvbmk0sal76c" ; int numBytes = str.Length * 5 / 8 ; byte [] bytes = new Byte[numBytes]; int bit_buffer; int currentCharIndex; int bits_in_buffer; if (str.Length < 3 ) { bytes[ 0 ] = ( byte )(table.IndexOf(str[ 0 ]) | table.IndexOf(str[ 1 ]) << 5 ); return System.Text.Encoding.UTF8.GetString(bytes); } bit_buffer = (table.IndexOf(str[ 0 ]) | table.IndexOf(str[ 1 ]) << 5 ); bits_in_buffer = 10 ; currentCharIndex = 2 ; for ( int i = 0 ; i < bytes.Length; i++) { bytes[i] = ( byte )bit_buffer; bit_buffer >>= 8 ; bits_in_buffer -= 8 ; while (bits_in_buffer < 8 && currentCharIndex < str.Length) { bit_buffer |= table.IndexOf(str[currentCharIndex++]) << bits_in_buffer; bits_in_buffer += 5 ; } } return System.Text.Encoding.UTF8.GetString(bytes); } When the malware encodes a domain using Method 2, it prepends the encrypted string with a double zero character: “00” . Following that, extracting a domain part of an encoded domain name (long form) is as simple as: static string get_domain_part( string s) { int i = s.IndexOf( ".appsync-api" ); if (i > 0 ) { s = s.Substring( 0 , i); if (s.Length > 16 ) { return s.Substring( 16 ); } } return "" ; } Once the domain part is extracted, the decoded domain name can be obtained by using Method 1 or Method 2, as explained above: if (domain.StartsWith( "00" )) { decoded = FromBase32String(domain.Substring( 2 )); } else { decoded = decode_domain(domain); } Decrypting the Victims’ Domain Names To see the decoder in action, let’s select 2 lists: List #1 Bambenek Consulting has provided a list of observed hostnames for the DGA domain. List #2 The second list has surfaced in a Paste bin paste , allegedly sourced from Zetalytics / Zonecruncher . NOTE: This list is fairly ‘noisy’, as it has non-decodable domain names. By feeding both lists to our decoder, we can now obtain a list of decoded domains, that could have been generated by the victims of the Sunburst backdoor. DISCLAIMER: It is not clear if the provided lists contain valid domain names that indeed belong to the victims. It is quite possible that the encoded domain names were produced by third-party tools, sandboxes, or by researchers that investigated and analysed the backdoor. The decoded domain names are provided purely as a reverse engineering exercise. The resulting list was manually processed to eliminate noise, and to exclude duplicate entries. Following that, we have made an attempt to map the obtained domain names to the company names, using Google search. Reader’s discretion is advised as such mappings could be inaccurate. Decoded Domain Mapping (Could Be Inaccurate) hgvc.com Hilton Grand Vacations Amerisaf AMERISAFE, Inc. kcpl.com Kansas City Power and Light Company SFBALLET San Francisco Ballet scif.com State Compensation Insurance Fund LOGOSTEC Logostec Ventilação Industrial ARYZTA.C ARYZTA Food Solutions bmrn.com BioMarin Pharmaceutical Inc. AHCCCS.S Arizona Health Care Cost Containment System nnge.org Next Generation Global Education cree.com Cree, Inc (semiconductor products) calsb.org The State Bar of California rbe.sk.ca Regina Public Schools cisco.com Cisco Systems pcsco.com Professional Computer Systems barrie.ca City of Barrie ripta.com Rhode Island Public Transit Authority uncity.dk UN City (Building in Denmark) bisco.int Boambee Industrial Supplies (Bisco) haifa.edu University of Haifa smsnet.pl SMSNET, Poland fcmat.org Fiscal Crisis and Management Assistance Team wiley.com Wiley (publishing) ciena.com Ciena (networking systems) belkin.com Belkin spsd.sk.ca Saskatoon Public Schools pqcorp.com PQ Corporation ftfcu.corp First Tech Federal Credit Union bop.com.pk The Bank of Punjab nvidia.com NVidia insead.org INSEAD (non-profit, private university) usd373.org Newton Public Schools agloan.ads American AgCredit pageaz.gov City of Page jarvis.lab Erich Jarvis Lab ch2news.tv Channel 2 (Israeli TV channel) bgeltd.com Bradford / Hammacher Remote Support Software dsh.ca.gov California Department of State Hospitals dotcomm.org Douglas Omaha Technology Commission sc.pima.gov Arizona Superior Court in Pima County itps.uk.net IT Professional Services, UK moncton.loc City of Moncton acmedctr.ad Alameda Health System csci-va.com Computer Systems Center Incorporated keyano.local Keyano College uis.kent.edu Kent State University alm.brand.dk Sydbank Group (Banking, Denmark) ironform.com Ironform (metal fabrication) corp.ncr.com NCR Corporation ap.serco.com Serco Asia Pacific int.sap.corp SAP mmhs-fla.org Cleveland Clinic Martin Health nswhealth.net NSW Health mixonhill.com Mixon Hill (intelligent transportation systems) bcofsa.com.ar Banco de Formosa ci.dublin.ca. Dublin, City in California siskiyous.edu College of the Siskiyous weioffice.com Walton Family Foundation ecobank.group Ecobank Group (Africa) corp.sana.com Sana Biotechnology med.ds.osd.mi US Gov Information System wz.hasbro.com Hasbro (Toy company) its.iastate.ed Iowa State University amr.corp.intel Intel cds.capilanou. Capilano University e-idsolutions. IDSolutions (video conferencing) helixwater.org Helix Water District detmir-group.r Detsky Mir (Russian children’s retailer) int.lukoil-int LUKOIL (Oil and gas company, Russia) ad.azarthritis Arizona Arthritis and Rheumatology Associates net.vestfor.dk Vestforbrænding allegronet.co. Allegronet (Cloud based services, Israel) us.deloitte.co Deloitte central.pima.g Pima County Government city.kingston. City of Kingston staff.technion Technion – Israel Institute of Technology airquality.org Sacramento Metropolitan Air Quality Management District phabahamas.org Public Hospitals Authority, Caribbean parametrix.com Parametrix (Engineering) ad.checkpoint. Check Point corp.riotinto. Rio Tinto (Mining company, Australia) intra.rakuten. Rakuten us.rwbaird.com Robert W. Baird & Co. (Financial services) ville.terrebonn Ville de Terrebonne woodruff-sawyer Woodruff-Sawyer & Co., Inc. fisherbartoninc Fisher Barton Group banccentral.com BancCentral Financial Services Corp. taylorfarms.com Taylor Fresh Foods neophotonics.co NeoPhotonics (optoelectronic devices) gloucesterva.ne Gloucester County magnoliaisd.loc Magnolia Independent School District zippertubing.co Zippertubing (Manufacturing) milledgeville.l Milledgeville (City in Georgia) digitalreachinc Digital Reach, Inc. deniz.denizbank DenizBank thoughtspot.int ThoughtSpot (Business intelligence) lufkintexas.net Lufkin (City in Texas) digitalsense.co Digital Sense (Cloud Services) wrbaustralia.ad W. R. Berkley Insurance Australia christieclinic. Christie Clinic Telehealth signaturebank.l Signature Bank dufferincounty. Dufferin County mountsinai.hosp Mount Sinai Hospital securview.local Securview Victory (Video Interface technology) weber-kunststof Weber Kunststoftechniek parentpay.local ParentPay (Cashless Payments) europapier.inte Europapier International AG molsoncoors.com Molson Coors Beverage Company fujitsugeneral. Fujitsu General cityofsacramento City of Sacramento ninewellshospita Ninewells Hospital fortsmithlibrary Fort Smith Public Library dokkenengineerin Dokken Engineering vantagedatacente Vantage Data Centers friendshipstateb Friendship State Bank clinicasierravis Clinica Sierra Vista ftsillapachecasi Apache Casino Hotel voceracommunicat Vocera (clinical communications) mutualofomahabanMutual of Omaha Bank Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call