There are new articles available, click to refresh the page.
Before yesterdayNCC Group Research

Detecting and Protecting when Remote Desktop Protocol (RDP) is open to the Internet

21 October 2021 at 16:48

Category:  Detection/Reduction/Prevention


Remote Desktop Protocol (RDP) is how users of Microsoft Windows systems can get a remote desktop on systems remotely to manage one or more workstations and/or servers.  With the increase of organizations opting for remote work, so to has RDP usage over the internet increased. However, RDP was not initially designed with the security and privacy features needed to use it securely over the internet. RDP communicates over the widely known port 3389 making it very easy to discover by criminal threat actors.  Furthermore, the default authentication method is limited to only a username and password.

The dangers of RDP exposure, and similar solutions such as TeamViewer (port 5958) and VNC (port 5900) are demonstrated in a recent report published by cybersecurity researchers at Coveware. The researchers found that 42 percent of ransomware cases in Q2 2021 leveraged RDP Compromise as an attack vector. They also found that “In Q2 email phishing and brute forcing exposed remote desktop protocol (RDP) remained the cheapest and thus most profitable and popular methods for threat actors to gain initial foot holds inside of corporate networks.” 

RDP has also had its fair share of critical vulnerabilities targeted by threat actors. For example, the BlueKeep vulnerability (CVE- 2019-0708) first reported in May 2019 was present in all unpatched versions of Microsoft Windows 2000 through Windows Server 2008 R2 and Windows 7.  Subsequently, September 2019 saw the release of a public wormable exploit for the RDP vulnerability.

The following details are provided to assist organizations in detecting, threat hunting, and reducing malicious RDP attempts.

The Challenge for Organizations

The limitations of authentication mechanisms for RDP significantly increases the risk to organizations with instances of exposed RDP to the internet. By default, RDP does not have a built-in multi-factor authentication (MFA). To add MFA to RDP logins, organizations will have to implement a Remote Desktop Gateway or place the RDP server behind a VPN that supports MFA. However, these additional controls add cost and complexity that some organizations may not be able to support.

The risk of exposed RDP is further highlighted through user propensity for password reuse. Employees using the same password for RDP as they do for other websites means if a website gets breached, threat actors will likely add that password to a list for use with brute force attempts.

Organizations with poor password policies are bound to the same pitfalls as password reuse for RDP.  Shorter and easily remembered passwords give threat actors an increased chance of success in the brute force of exposed RDP instances.

Another challenge is that organizations do not often monitor RDP logins, allowing successful RDP compromises to go undetected. In the event that RDP logins are collected, organizations should work to make sure that, at the very least, timestamps, IP addresses, and the country or city of the login are ingested into a log management solution.


Detecting the use of RDP is something that is captured in several logs within a Microsoft Windows environment. Unfortunately, most organizations do not have a log management or SIEM solution to collect the logs that could alert to misuse, furthering the challenge to organizations to secure RDP. 

RDP Access in the logs

RDP logons or attacks will generate several log events in several event logs.  These events will be found on the target systems that had RDP sessions attempted or completed, or Active directory that handled the authentication.  These events would need to be collected into a log management or SIEM solution in order to create alerts for RDP behavior.  There are also events on the source system that can be collected, but we will save that for another blog.

Being that multiple log sources contain RDP details, why collect more than one? The devil is in the details, and in the case of RDP artifacts, various events from different log sources can provide greater clarity of RDP activities. For investigations, the more logs, the better if malicious behavior is suspected.

Of course, organizations have to consider log management volume when ingesting new log sources, and many organizations do not collect workstation endpoint logs where RDP logs are generated. However, some of the logs specific to RDP will generally have a low quantity of events and are likely not to impact a log management volume or license. This is especially true because RDP logs are only found on the target system, and typically RDP is seldom used for workstations.

Generally, if you can collect a low noise/volume high validity event from all endpoints into a log management solution, the better your malicious detection can be. An organization will need to test and decide which events to ingest based collectively on their environment, log management solution, and the impact on licensing and volume.

The Windows Advanced Audit Policy will need to have the following policy enabled to collect these events:

  • Logon/Logoff – Audit Logon = Success and Failed

The following query logic can be used and contain a lot of details about all authentication to a system, so a high volume event:

  • Event Log = Security
  • Event ID = 4624 (success)
  • Event ID = 4625 (failed)
  • Logon Type = 10 (RDP)
  • Account Name = The user name logging off
  • Workstation Name = This will be from the log of system being logged off from

Optionally, another logon can be enabled to collect RDP events, but this will also generate a lot of other logon noise.  The Windows Advanced Audit Policy will need to have the following policy enabled to collect these events:

  • Logon/Logoff – Other Logon/Logoff Events = Success and Failed

The following query logic can be used and contain a few details about session authentication to a system, so a low volume event:

  • Event Log = Security
  • Event ID = 4778 (connect)
  • Event ID = 4779 (disconnect)
  • Account Name = The user name logging off
  • Session Name = RDP-Tcp#3
  • Client Name = This will be the system name of the source system making the RDP connection
  • Client Address = This will be the IP address of the source system making the RDP connection

There are also several RDP logs that will record valuable events that can be investigated during an incident to determine the source of the RDP login.  Fortunately, the Windows Advanced Audit Policy will not need to be updated to collect these events and are on by default:

The following query logic can be used and contain a few details about RDP connections to a system, so a low volume event:

  • Event Log = Microsoft-Windows-TerminalServices-LocalSessionManager
  • Event ID = 21 (RDP connect)
  • Event ID = 24 (RDP disconnect)
  • User = The user that made the RDP connection
  • Source Network Address = The system where the RDP connection originated
  • Message = The connection type

The nice thing about having these logs is that even if a threat actor clears the log before disconnecting, the Event ID 24 (disconnect) will be created after the logs have been cleared and then the user disconnects.  This allows tracing of the path of the user and/or treat actor took from system to system.

The following query logic can be used and contain a few details about RDP connections to a system, so a low volume event:

Event Log = Microsoft-Windows-TerminalServices-RemoteConnectionManager

  • Event ID = 1149 (RDP connect)
  • User = The user that made the RDP connection
  • Source Network Address = The system where the RDP connection originated

Event Log = Microsoft-Windows-TerminalServices-RDPClient

  • Event ID = 1024 (RDP connection attempt)
  • Event ID = 1102 (RDP connect)
  • Message = The system where the RDP connection originated

Threat Hunting

The event IDs previously mentioned would be a good place to start when hunting for RDP access. Since RDP logs are found on the target host, an organization will need to have a solution or way to check each workstation and server for these events in the appropriate log or use a log management SIEM solution to perform searches. Threat actors may clear one or more logs before disconnecting, but fortunately, the disconnect event will be in the logs allowing the investigator to see the source of the RDP disconnect. This disconnect (event ID 24) can be used to focus hunts on finding the initial access point of the RDP connection if the logs are cleared.


The best and easiest option to reduce the likelihood of malicious RDP attempts is to remove RDP from being accessible from the internet.  NCC Group has investigated many incidents where our customers have had RDP open to the internet only to find that it was actively under attack without the client knowing it or the source of the compromise.  Knowing that RDP is highly vulnerable, as the Coveware report states, removing RDP from the internet, securing it, or finding another alternative is the highest recommendation NCC Group can make for organizations that need RDP for remote desktop functions.

Remote Desktop Gateway

Remote Desktop Gateway (RD Gateway) is a role that is added to a Windows Server that you publish to the internet that provides SSL (encrypted RDP over ports TCP 443 and UDP 3391) access instead of the RDP protocol over port 3389.  The RD Gateway option is more secure than just RDP alone, but still should be protected with MFA.

Virtual Private Network (VPN)

Another standard option to reduce malicious RDP attempts is to use RDP behind a VPN.  If VPN infrastructure is already in place, organizations have, or can easily adjust their firewalls to meet this.  Organizations should also monitor VPN logins for access attempts, and the source IP resolved to the country of origin.  Known good IP addresses for users can be implemented to reduce the noise of voluminous VPN access alerts and highlight anomalies.

Jump Host

Many organizations utilize jump hosts protected by MFA to authenticate before to internal systems via RDP.  However, keep in mind that jump hosts face the internet and are thus susceptible to flaws in the jump host application. Therefore, organizations should monitor the jump host application and apply patches as fast as possible.

Cloud RDP

Another option is to use a cloud environment like Microsoft Azure to host a remote solution that provides MFA to deliver trusted connections back to the organization.

Change the RDP Listening Port

Although not recommended to simply prevent RDP attacks, swapping the default port from 3389 to another port can be helpful from a detection standpoint. By editing the Windows registry, the default listening port can be modified, and organizations can implement a SIEM detection to capture port 3389 attempts. However, keep in mind that even though the port changes, recon scans can easily detect RDP listening on a given port in which an attacker can then change their port target.

IP Address restrictions

Lastly, organizations can use a dedicated firewall appliance or Windows Firewall on the host machines managed by Group Policy to restrict RDP connections to known good IP addresses. However, this option comes with a high administrative burden as more users are provisioned or travel for work. Nevertheless, this option is often the best short-term solution to secure RDP until one of the more robust solutions can be engineered and put in place.


Organizations should take careful consideration when utilizing RDP over the internet. We hope this blog entry helps provide options to reduce the risk of infection and compromise from ever-increasing attacks on RDP, as well as some things to consider when implementing and using RDP. 

References and Additional Reading

Detecting and Hunting for the PetitPotam NTLM Relay Attack

23 September 2021 at 18:34


During the week of July 19th, 2021, information security researchers published a proof of concept tool named “PetitPotam” that exploits a flaw in Microsoft Windows Active Directory Certificate Servers with an NTLM relay attack.  The flaw allows an attacker to gain administrative privileges of an Active Directory Certificate Server once on the network with another exploit or malware infecting a system.  

The following details are provided to assist organizations in detecting and threat hunting for this and other similar types of threats.


The default settings of Windows logging do not often catch advanced threats.  Therefore, Windows Advanced Audit Logging must be optimally configured to detect and to be able to threat hunt PetitPotam and similar attacks.

Organizations should have a standard procedure to configure the Windows Advanced Audit Policies as a part of a complete security program and have each Windows system collect locally significant events.  NCC Group recommends using the following resource to configure Windows Advanced Audit Policies:

Log rotation can be another major issue with Windows default log settings.  Both the default log size should be increased to support detection engineering and threat hunting.

Ideally, organizations should forward event logs to a log management or SIEM solution to operationalize detection alerts and provide a central console where threat hunting can be performed.  Alternatively, with optimally configured log sizes, teams can run tools such as PowerShell or LOG-MD to hunt for malicious activity against the local log data.

Detecting and Threat Hunting NTLM Relay Attacks

The PetitPotam attack targets Active Directory servers running certificate services, so this will be the focus of the detection and hunting.  Event log data is needed to detect or hunt for PetitPotam. The following settings and events can be used to detect this malicious activity:

Malicious Logins

PetitPotam will generate an odd login that can be used to detect and hunt for indications of execution.  To collect Event ID 4624, the Windows Advanced Audit Policy will need to have the following policy enabled:

  • Logon/Logoff – Audit Logon = Success and Failure

The following query logic can be used:

  • Event Log = Security
  • Event ID = 4624
  • Authentication Package Name = NTLM*
  • Elevated Token – *1842

Sample Query

The following query is based on Elastic’s WinLogBeat version 7 agent.

  • “event.code”=”4624″ and winlog.event_data.AuthenticationPackageName=”NTLM*” and winlog.event_data.ElevatedToken=”*1842″ | PackageName:=winlog.event_data.AuthenticationPackageName | Token:=winlog.event_data.ElevatedToken | WS_Name:=winlog.event_data.WorkstationName | LogonProcess:=winlog.event_data.LogonProcessName | LogonType:=winlog.event_data.LogonType | ProcessName:=winlog.event_data.ProcessName | UserName:=winlog.event_data.SubjectUserName | Domain:=winlog.event_data.SubjectDomainName | TargetDomain:=winlog.event_data.TargetDomainName | TargetUser:=winlog.event_data.TargetUserName | Task:=winlog.event_data.TargetUserName| table([event.code, @timestamp, host.name, event.outcome, WS_Name, UserName, Domain, Token, PackageName, LogonProcess, LogonType, ProcessName, TargetDomain, TargetUser, Task])

Malicious Share Access

PetitPotam will generate odd network share connections that can be used to detect and hunt for indications of execution.  To collect Event ID 5145, the Windows Advanced Audit Policy will need to have the following policy enabled:

  • Object Access – Audit Detailed File Share = Success
  • Object Access – File Share = Success

The following query logic can be used:

  • Event Log = Security
  • Event ID = 5145
  • Object Name = *IPC*
  • Target Name = (“lsarpc” or “efsrpc” or “lsass” or “samr” or “netlogon”

Sample Query

The following query is based on Elastic’s WinLogBeat version 7 agent.

  • “event.code”=”5145” and winlog.event_data.ShareName=*IPC* and (“lsarpc” or “efsrpc” or “lsass” or “samr” or “netlogon” or “srvsvc”)
    | Status:= keywords[0] | Src_IP:= winlog.event_data.IpAddress | PID:= winlog.process.pid | UserName:=winlog.event_data.SubjectUserName | Domain:= winlog.event_data.SubjectDomainName | Target_File:= winlog.event_data.RelativeTargetName | Path:= winlog.event_data.ShareLocalPath | Share:= winlog.event_data.ShareName | ObjectType:=winlog.event_data.ObjectType
    | table([event.code, @timestamp, host.name, Status, Src_IP, PID, UserName, Domain, task, Path, Share, Target_File, ObjectType])

If you find any false positives, validating them and excluding or refining the query may be needed.  We hope this information can assist your detection and threat hunting efforts to detect this and similar types of attacks.

Additional Reading and Resources

Disabling Office Macros to Reduce Malware Infections

16 August 2021 at 17:38

Category:  Reduction/Prevention


Document macros have gone in and out of style since 1995 as a deployment method for malware. Netskope’s latest ‘Cloud and Threat Report: July 2021 Edition’ points out that in Q2 of 2021, Microsoft Office macros accounted for 43% of malicious Office document downloads, compared to just 20% at the beginning of 2020.  Malicious Office documents, aka maldocs, have continued to be an issue for organizations.  Emotet, a successful malware family taken down in 2020, heavily used Office macros to infect Microsoft Windows systems.  Other malware groups seemed to have taken a page from the Emotet playbook and increased the use of macros in their recent campaigns of 2021. Today let us take a look at the various methods of detection and prevention of malicious macros.

Enabled Macros by Default

Microsoft Office by default allows a user to enable content and allow macros to run when opening Office documents like Word, Excel, and even PowerPoint.  Macros or enabled content is rarely used by most users, and typically just a handful of users needing or using Excel financial calculations.  Most organizations are scared or uncertain about what will break if macros are disabled.  Creating a communication plan informing the organization about the upcoming change and providing a way for users to request and justify the need for macros, get any needed approvals, and required training can help avoid significant adverse impacts to the organization once implemented. 


Detecting the use of macros within Office programs is not easy as there are no logging events associated with macro usage. The only option is to look for programs executed after the launch of Office programs. Often malware will use the macro to launch a scripting engine such as cscript, wscript, or other scripting languages. Additionally, PowerShell, WMI, or other administrative Windows utilities have also been used in this context.  Endpoint Detection and Response solutions (EDR) usually monitor these parent-child relationships and trigger when Office documents attempt to execute nonstandard programs. Similarly, an organization with robust and proper logging of endpoint behavior can build detections within their log management or SIEM solution to highlight odd Office document executions.


The best and easiest option to reduce the likelihood of malicious Office documents crippling an organization with malware or ransomware is to disable Office macros and create an allow list for users that absolutely need macros or enabled content. Users with exceptions to run macros or enabled content should be a priority to monitor for maldoc behavior through suspicious parent-child Office executions.

Blocking all Office documents from coming into the organization is not feasible due to the widespread usage of Microsoft Office products. However, some email scanning gateways offer maldoc scanning at an additional cost and can effectively reduce the sheer quantity of malicious Office documents an organization receives.  Alternatively, implementing an EDR solution is also a viable option.

Disabling Office macros is the easiest as it is FREE and already built into Microsoft Active Directory as a Group Policy object. The image below depicts the setting to disable Office macros.

Organizations can utilize user groups for those exceptions that still require macro functionality. However, keep in mind that those specific users should be provided additional awareness training on the ramifications of opening malicious Office documents and enabling content.

Use the Registry to block macros

For those that do not have Active Directory, blocking macros can also be achieved by adding a registry setting to each system to disable macro usage. Set the following keys to achieve macro blocking and be sure to adjust the appropriate Office version, e.g., “15.0, 16.0, etc.”:

  • HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\<16.0>\word\security
  • HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\<16.0>\excel\security
  • HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\<16.0>\powerpoint\security

In each key listed above, create the following value:

  • DWORD: blockcontentexecutionfrominternet
    • Value = 1


We hope this blog entry helps provide an option to reduce the risk of infection from ever-increasing malicious Office documents and some things to consider when implementing the change.  With some preparation, communication, and education, an organization can reduce the likelihood of getting infected by maldocs with an existing FREE option available to all Windows users.

References and Additional Reading

Detecting and Hunting for the Malicious NetFilter Driver

16 July 2021 at 21:26

Category:  Detection and Threat Hunting


During the week of June 21st, 2021, information security researchers from G Data discovered that a driver for Microsoft Windows named “netfilter.sys” had a backdoor added by a 3rd party that Microsoft then signed as a part of the Microsoft OEM program.  The malicious file is installed on a victim’s system as a component of an attack as part of the post-exploitation process. This means that the attacker must either have gained administrative privileges or already had access to run the installer to update the registry and install the malicious driver. This can occur during the post-exploitation process or set up to install the next time the system starts. Additionally, the victim can be convinced to install the driver as part of a pretexting attack.  At present, Microsoft has not seen the enterprise environment targeted, rather individual users at this time.

The following details are provided to assist organizations in detecting and threat hunting for this specific threat and other similar types of threats.

Investigating Malicious Drivers

Several tools can be used to check systems for indications of malicious drivers.  For example, tools such as SysInternals Autoruns and LOG-MD can investigate autoruns or persistence entries, with drivers being one type of persistence on a Windows server and workstation systems.

On a Windows system, drivers tend to be loaded from typically three locations:

  • C:\Windows\System32\Drivers
  • C:\WINDOWS\system32\DriverStore\FileRepository
  • Applications installed directory typically under “Program Files” or “Program Files x86”.

The malicious netfilter driver, in this case, can be found in a folder that drivers should never exist.  The odd driver location is a good artifact for execution detection and threat hunting. Any binary found in the following folder should be investigated:

  • %AppData% – C:\Users\<username>\AppData\Roaming

Windows also provides a built-in utility “driverquery” that can list the drivers, the state of the driver (running or stopped), and the driver’s key (location from which the driver was loaded).  To get a list of all the drivers of a system into CSV format that can then be opened in Microsoft Excel, execute the following command in an administrative command prompt:

  • driverquery /v /fo CSV | find /i /v “system32\drivers\” | find /i /v “driverstore” > C:\Windows\Temp\Driver_List_%computername%.csv

This command will filter out the two primary locations drivers are loaded, providing a short list of drivers on the system that should be investigated.  This command also includes the name of the system appended to the output filename to allow for easier review of artifacts collected from multiple systems.


Detecting the netfilter driver and similar malicious payloads is as simple as looking for binaries and drivers loaded from atypical locations. Add a rule to your SIEM, log management, EDR, or similar security tooling that looks for process execution (event ID 4688 of the Windows security log) from the following locations:

  • C:\Program Files
  • C:\Program Files x86
  • C:\ProgramData
  • %AppData% – C:\Users\<username>\AppData\Roaming
  • %LocalAppData% – C:\Users\<username>\AppData\Local

In order to collect event ID 4688, the Windows Advanced Audit Policy will need to have the following policy enabled:

  • Detailed Tracking – Audit Process Creation

We hope this information can assist in your detection and threat hunting efforts to detect this and similar types of attacks.


The following indicators of compromise (IOCs) are provided to help in detection and threat hunting activities.

Folders the file(s) can be found

  • %AppData% – C:\Users\<username>\AppData\Roaming


  • Netfilter.sys
  • Sdl.sys
  • File.sys

IP Addresses

  • 110.42.4[.]180
  • 45.113.202[.]180

File Hashes

  • 04a269dd0a03e32e5b2a1c8ab0768791962e040d080d44dc44dab01dd7954f2b
  • 0856a1da15b2b3e8999bf9fc51bbdedd4051e21fab1302e2ce766180b4931d86
  • 0c42fe45ffa9a9c36c87a7f01510a077da6340ffd86bf8509f02c6939da133c5
  • 0eace788e09c8d3f793a1fad94d35bcfd233f0777873412cd0c8172865562eec
  • 115034373fc0ec8f75fb075b7a7011b603259ecc0aca271445e559b5404a1406
  • 12656fc113b178fa3e6bfffc6473897766c44120082483eb8059ebff29b5d2df
  • 12c0002af719c6abbc1e726b409fce099fffb90f758477f5295c152bde504caa
  • 16b6be03495a4f4cf394194566bb02061fba2256cc04dcbde5aa6a17e41b7650
  • 18b923b169b2c3c7db5cbfda0db0999f04adb2cf6c917e5b1fb2ff04714ecac1
  • 1aa8ba45f9524847e2a36c0dc6fd80162923e88dc1be217dde2fb5894c65ff43
  • 1cd75de5f54b799b60789696587b56a4a793cf60775b81f236f0e65189d863af
  • 1d1f7e26109e6cb28c6b369c937b407d7b0cce3c4800ce9852eda94742b12259
  • 1d60819f0ab8547dcd4eb18d39a0c317ec826332afa19c0a6af94bc681a21f14
  • 1f05f74ebae7e65d389703d423445ffb269e657d8278b0523417e1f72b0228eb
  • 1f90d9c4d259c1fde4c7bb66a95d71ea0122e4dfb75883a6cb17b5c80ce6d18a
  • 22da5a055b7b17c69def9f5af54e257c751507e7b6b9a835fcf6245ab90ae750
  • 22f6fe6bd62fb03f7aee489cccbc918999f49596052ac0153c02cd7a3320de13
  • 23c061933d471c1f959c77806098ec0528d9b1d0130689bb3f417dd843138468
  • 24ea733bae1b8722841fb4c6cead93c4c4f0b1248ca9a21601b1ce6b95b06864
  • 26d67d479dafe6b33c980bd1eed0b6d749f43d05d001c5dcaaf5fcddb9b899fe
  • 26f2b9cf6e0fb50bad49a367bee63e808f1d53c476b38642d13c7db6e50687f4
  • 2fa78c2988f9580b0c18822b117d065fb419f9c476f4cfa43925ba6cd2dffac3
  • 314affdc86f62c8f8069ccd50a2cdf73bcd319773a031be700ba97a1ea4129a8
  • 34c890fa43ca0e5165a4960549828ba43d7f48a216a22fc46204548ebfc34f72
  • 3700b38d63d426ff0a985226b45eca6e24d052f4262d12aff529e62c2cb889c3
  • 40c45c9b1c764777096b59f99ae524cbd25b88c805187e615c3ed6840f3d4c15
  • 45ee083e28fbb33afa41b1b8cd00d94c29dea8cb7cee70bae4079e6c3dfb5501
  • 4ce61ad21f186cf10dbcc253feee31262203cb5c12c5a140d2dda5447c57aba1
  • 516159871730b18c2bddedb1a9da110577112d4835606ee79bb80e7a58784a13
  • 5cb1dc26159c6700d6cadece63f6defda642ec1a6d324daefb0965b4e3746f70
  • 5d0d5373c5e52c4405f4bd963413e6ef3490b7c4c919ec2d4e3fb92e91f397a0
  • 62d7c5465852cdb7b59a86c20b4de5991c8f4820ce11a7c01cf0dde6032e500d
  • 630d7bdc20f33e6f822f52533a324865694886b7b74dfaad1dc30c9aee4260a2
  • 635273eaa4c2e20c4ec320c6c8447ce2e881984e97c9ed6aeec4fad16b934e81
  • 63d61549030fcf46ff1dc138122580b4364f0fe99e6b068bc6a3d6903656aff0
  • 640eeb3128ae5c353034ee29cb656d38c41353743396c1c936afd4d04a782087
  • 6703400b490b35bcde6e41ce1640920251855e6d94171170ae7ea22cdd0938c0
  • 6a234a2b8eb3844f7b5831ee048f88e8a76e9d38e753cc82f61b234c79fe1660
  • 6a6db5febdaf3f1577bf97c6e1e24913e6c78b134062c02fd1f9875099c03a3f
  • 6c7f24d8ed000bc7ce842e4875b467f9de1626436e051bd351adf1f6f8bbacf8
  • 70b63dfc3ed2b89a4eb8a0aa6c26885f460e5686d21c9d32413df0cdc5f962c7
  • 79e7165e626c7bde546cd1bea4b9ec206de8bed7821479856bdb0a2adc3e3617
  • 7ff8fe4c220cf6416984b70a7e272006a018e5662da3cedc2a88efeb6411b4a4
  • 8249e9c0ac0840a36d9a5b9ff3e217198a2f533159acd4bf3d9b0132cc079870
  • 8e0b330a8df3076153638f5b76afc24d1083ebccc60e4d63ee0df5c11c45d58a
  • 93d99a5fbfc888c0a40a18946933121ae110229dcf206b4d17116a57e7cf4dc9
  • 97030f3c81906334429afebbf365a89b66804ed890cd74038815ca18823d626c
  • 9b55b35284346bbcdc2754e60517e1702f0286770a080ee6ff3e7eed1cab812a
  • 9f9315790d0b0cc5213ac9a8eff0968cccc0a6c469b50d6598ce759748fe74bf
  • 9f9ebd6cd9b5b33ab2780122ee9c5feec84927f362890a062d13ef9816c7b85f
  • a0050c33c8263da02618872d642617959b3564fe173985e078bfedb89df93724
  • aa97f4f98ff842b1bfd78e920fcb1dedaec3f882dd19311bba6037430868e7a7
  • ad2dd8a68ce22d0959f341e9269e8033b34362b34bdea50b8ee2390907f1a610
  • b2cd9cca011064d03ddd8fe3521ce0e9f9d8b16f63e4ecaf03eacfef47d22dbf
  • b7516dca419d087ef844c42e061a834908f34e7363577ab128094973896222c8
  • b847e717215e0198cb4e863bd96390613f83eb92693171be50ca14255c5fb088
  • bbc58fd69ce5fed6691dd8d2084e9b728add808ffd5ea8b42ac284b686f77d9a
  • bfb4603902c6c9ff32bc36113280ee8b5687cc3ef4c0ff9fc56f2925c7f342f0
  • c0e74f565237c32989cb81234f4b5ad85f9dd731c112847c0a143d771021cb99
  • c2f23ad4e2f12c490cfd589764464e293d5d56c31b6b3f5081e2d677384cb2fe
  • c95af9eb52111b72563875d85d593d96d7e54e19690827a052377c77cc80e06f
  • caa0d9bb7ed2d21a76b71dfc22ffaef80371de8af2a03b8103cbcec332897a88
  • d0e1639e6386ef3c063bfae334fcc35cdfa85068ac1a65bb58f2463276c31ac9
  • d1ac4d07ba6fe1dd988c471975e49e35b83d03a9b9d626fa524fd8300b80b14a
  • d4335f4189240a3bcafa05fab01f0707cc8e3dd7a2998af734c24916d9e37ca8
  • d60fdabaf5a0ab375361d2ed1a9b39832bdb8bd33466d6c43d42a48ba2ffd274
  • e0afb8b937a5907fbe55a1d1cc7574e9304007ef33fa80ff3896e997a1beaf37
  • e2449ccc74e745c0339850064313bdd8dc0eff17b3a4e0882184c9576ac93a89
  • e8e7f2f889948fd977b5941e6897921da28c8898a9ca1379816d9f3fa9bc40ff
  • edc6e32e3545f859e5b49ece1cabd13623122c1f03a2f7454a61034b3ff577ed
  • ee6d0d0ea24be622521ee1a4defa5d5729b99ee2217ac65701d38d05dbc0d4e6
  • f1718a005232d1261894b798a60c73d971416359b70d0e545d7e7a40ed742b71
  • f83c357106a7d1d055b5cb75c8414aa3219354deb16ae9ee7efe8ee4c8c670ca
  • fd8a5313bf63f5013dc126620276fb4f0ef26416db48ee88cbaaca4029df1d73

Additional Reading

  • There are no more articles