Tag Archives: Security

Security

Scanning for Laravel – a PHP Framework for Web Artisants, (Sat, Sep 23rd)

Leave a comment
This post was originally published on this site

Today while reviewing my honeypot logs, I noticed an HTTP request for a directory this week I had not noticed before that included Laravel:

  • /laravel
  • /laravel/.env
  • /laravel/.env.example
  • /vendor/laravel/.env
  • /vendor/.env
  • /project/env.example
  • /staging2.env.example
  • /public/.env

This is only a short list of directories these IPs were probing for. After a search across all the logs I have for the past year, the honeypot captured a few times this activity looking for this application. Checking ISC Web Application logs, scanning for Laravel peaked between February and mid April 2023. The last know exploit for this application was for CVE-2021-3129 for a Remote Code Execution (RCE).

Active scanning likely looking for any misconfigured applications.This is a list of the IPs captured in the past 3 months:

[1] https://laravel.com
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129
[3] https://isc.sans.edu/ipinfo.html?ip=4.17.224.133
[4] https://isc.sans.edu/ipinfo.html?ip=51.222.44.56

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Apple Patches Three New 0-Day Vulnerabilities Affecting iOS/iPadOS/watchOS/macOS, (Thu, Sep 21st)

Leave a comment
This post was originally published on this site

This update patches three already exploited vulnerabilities:
(1) CVE-2023-41993 Remote code execution in WebKit. This could be used as an initial access vector
(2) CVE-2023-41992 Privilege Escalation. A follow-up after the initial access was achieved via the first vulnerability
(3) CVE-2023-41991 Certificate Validation Issue. A malicious app installed via 1 and 2 may be more difficult to detect due to this vulnerability

Patches are available for all currently supported operating systems and Safari to address the WebKit vulnerability.

iOS 17 (just released this week), as well as iOS 16, is vulnerable.

CVSS numbers below are not "official" but generated with some help from ChatGPT based on the vulnerability description. Used them as rough indicators of severity.

Safari 16.6.1 iOS 17.0.1 and iPadOS 17.0.1 iOS 16.7 and iPadOS 16.7 watchOS 10.0.1 watchOS 9.6.3 macOS Ventura 13.6 macOS Monterey 12.7
CVE-2023-41993 [critical] ChatGPT-CVSS: CVSS score: 9.8 *** EXPLOITED *** WebKit
The issue was addressed with improved checks.
Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.
x x x     x  
CVE-2023-41992 [moderate] ChatGPT-CVSS: 7.0. *** EXPLOITED *** Kernel
The issue was addressed with improved checks.
A local attacker may be able to elevate their privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.
  x x x x x x
CVE-2023-41991 [important] ChatGPT-CVSS: 7.0 *** EXPLOITED *** Security
A certificate validation issue was addressed.
A malicious app may be able to bypass signature validation. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.
  x x x x x  

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

What's Normal? DNS TTL Values, (Wed, Sep 20th)

Leave a comment
This post was originally published on this site

I am trying to start a series of brief diaries about "what's normal." Analysts often only look at the network when they suspect something is wrong. But to find the anomaly, someone must first know what's normal. So, I am trying to collect data from my home network to show what to consider. The values I am presenting here are normal for my home network and will likely differ for your network. So, instead of just copying/pasting, run the experiment yourself 🙂

Security

Obfuscated Scans for Older Adobe Experience Manager Vulnerabilities, (Tue, Sep 19th)

Leave a comment
This post was originally published on this site

Adobe Experience Manager (AEM) is a complex enterprise-level content management system built around open-source products like Apache Sling, Jackrabbit/Oak, and Felix. Just last week, Adobe patched another XSS vulnerability in AEM. But the scans we see now target older vulnerabilities, likely a vulnerability 2-3 years old.

Security

#StopRansomware: Snatch Ransomware

Leave a comment
This post was originally published on this site

SUMMARY

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known ransomware IOCs and TTPs associated with the Snatch ransomware variant identified through FBI investigations as recently as June 1, 2023.

Since mid-2021, Snatch threat actors have consistently evolved their tactics to take advantage of current trends in the cybercriminal space and leveraged successes of other ransomware variants’ operations. Snatch threat actors have targeted a wide range of critical infrastructure sectors including the Defense Industrial Base (DIB), Food and Agriculture, and Information Technology sectors. Snatch threat actors conduct ransomware operations involving data exfiltration and double extortion. After data exfiltration often involving direct communications with victims demanding ransom, Snatch threat actors may threaten victims with double extortion, where the victims’ data will be posted on Snatch’s extortion blog if the ransom goes unpaid.

FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.

Download the PDF version of this report:

AA23-263A.pdf
(PDF, 578.71 KB
)

For a downloadable copy of IOCs, see:

AA23-263A STIX XML
(XML, 79.84 KB
)
AA23-263A STIX JSON
(JSON, 56.10 KB
)

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 13. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

First appearing in 2018, Snatch operates a ransomware-as-a-service (RaaS) model and claimed their first U.S.-based victim in 2019. Originally, the group was referred to as Team Truniger, based on the nickname of a key group member, Truniger, who previously operated as a GandCrab affiliate. Snatch threat actors use a customized ransomware variant notable for rebooting devices into Safe Mode [T1562.009], enabling the ransomware to circumvent detection by antivirus or endpoint protection, and then encrypting files when few services are running.

Snatch threat actors have been observed purchasing previously stolen data from other ransomware variants in an attempt to further exploit victims into paying a ransom to avoid having their data released on Snatch’s extortion blog. Note: Since November 2021, an extortion site operating under the name Snatch served as a clearinghouse for data exfiltrated or stolen from victim companies on Clearnet and TOR hosted by a bulletproof hosting service. In August 2023, individuals claiming to be associated with the blog gave a media interview claiming the blog was not associated with Snatch ransomware and “none of our targets has been attacked by Ransomware Snatch…”, despite multiple confirmed Snatch victims’ data appearing on the blog alongside victims associated with other ransomware groups, notably Nokoyawa and Conti.[1]

Initial Access and Persistence

Snatch threat actors employ several different methods to gain access to and maintain persistence on a victim’s network. Snatch affiliates primarily rely on exploiting weaknesses in Remote Desktop Protocol (RDP) [T1133] for brute-forcing and gaining administrator credentials to victims’ networks [T1110.001]. In some instances, Snatch affiliates have sought out compromised credentials from criminal forums/marketplaces [T1078].

Snatch threat actors gain persistence on a victim’s network by compromising an administrator account [T1078.002] and establishing connections over port 443 [T1071.001] to a command and control (C2) server located on a Russian bulletproof hosting service [T1583.003]. Per IP traffic from event logs provided by recent victims, Snatch threat actors initiated RDP connections from a Russian bulletproof hosting service and through other virtual private network (VPN) services [T1133].

Data Discovery and Lateral Movement

Snatch threat actors were observed using different TTPs to discover data, move laterally, and search for data to exfiltrate. Snatch threat actors use sc.exe to configure, query, stop, start, delete, and add system services using the Windows Command line. In addition to sc.exe, Snatch threat actors also use tools such as Metasploit and Cobalt Strike [S0154].

Prior to deploying the ransomware, Snatch threat actors were observed spending up to three months on a victim’s system. Within this timeframe, Snatch threat actors exploited the victim’s network [T1590], moving laterally across the victim’s network with RDP [T1021.001] for the largest possible deployment of ransomware and searching for files and folders [T1005] for data exfiltration [TA0010] followed by file encryption [T1486].

Defense Evasion and Execution

During the early stages of ransomware deployment, Snatch threat actors attempt to disable antivirus software [T1562.001] and run an executable as a file named safe.exe or some variation thereof. In recent victims, the ransomware executable’s name consisted of a string of hexadecimal characters which match the SHA-256 hash of the file in an effort to defeat rule-based detection [T1036]. Upon initiation, the Snatch ransomware payload queries and modifies registry keys [T1012][T1112], uses various native Windows tools to enumerate the system [T1569.002], finds processes [T1057], and creates benign processes to execute Windows batch (.bat) files [T1059.003]. In some instances, the program attempts to remove all the volume shadow copies from a system [T1490]. After the execution of the batch files, the executable removes the batch files from the victim’s filesystem [T1070.004].

The Snatch ransomware executable appends a series of hexadecimal characters to each file and folder name it encrypts—unique to each infection—and leaves behind a text file titled HOW TO RESTORE YOUR FILES.TXT in each folder. Snatch threat actors communicate with their victims through email and the Tox communication platform based on identifiers left in ransom notes or through their extortion blog. Since November 2021, some victims reported receiving a spoofed call from an unknown female who claimed association with Snatch and directed them to the group’s extortion site. In some instances, Snatch victims had a different ransomware variant deployed on their systems, but received a ransom note from Snatch threat actors. As a result, the victims’ data is posted on the ransomware blog involving the different ransomware variant and on the Snatch threat actors’ extortion blog.

Indicators of Compromise (IOCs)

The Snatch IOCs detailed in this section were obtained through FBI investigations from September 2022 through June 2023.

Email Domains and Addresses

Since 2019, Snatch threat actors have used numerous email addresses to email victims. Email addresses used by Snatch threat actors are random but usually originate from one of the following domains listed in Tables 1 and 2:

Table 1: Malicious Email Domains Observed in Use by Snatch Threat Actors

Email Domains

sezname[.]cz

cock[.]li

airmail[.]cc

Table 2 shows a list of legitimate email domains offering encrypted email services that have been used by Snatch threat actors. These email domains are all publicly available and legal. The use of these email domains by a threat actor should not be attributed to the email domains, absent specific articulable facts tending to show they are used at the direction or under the control of a threat actor.

Table 2: Legitimate Email Domains Observed in Use by Snatch Threat Actors

Email Domains

tutanota[.]com / tutamail[.]com / tuta[.]io

mail[.]fr

keemail[.]me

protonmail[.]com / proton[.]me

swisscows[.]email

The email addresses listed in Table 3 were reported by recent victims.

Table 3: Snatch’s Email Addresses Reported by Recent Victims

Email Addresses

sn.tchnews.top@protonmail[.]me

funny385@swisscows[.]email

funny385@proton[.]me

russellrspeck@seznam[.]cz

russellrspeck@protonmail[.]com

Mailz13MoraleS@proton[.]me

datasto100@tutanota[.]com

snatch.vip@protonmail[.]com
TOX Messaging IDs

TOX Messaging IDs

CAB3D74D1DADE95B52928E4D9DFC003FF5ADB2E082F59377D049A91952E8BB3B419DB2FA9D3F

7229828E766B9058D329B2B4BC0EDDD11612CBCCFA4811532CABC76ACF703074E0D1501F8418

83E6E3CFEC0E4C8E7F7B6E01F6E86CF70AE8D4E75A59126A2C52FE9F568B4072CA78EF2B3C97

0FF26770BFAEAD95194506E6970CC1C395B04159038D785DE316F05CE6DE67324C6038727A58

NOTE: According to ransom notes, this is a “Customer service” TOX to reach out to if the original TOX ID does not respond.
Folder Creation

Folder Creation

C:$SysReset
Filenames with Associated SHA-256 Hashes

Filenames

SHA-256

qesbdksdvnotrjnexutx.bat

0965cb8ee38adedd9ba06bdad9220a35890c2df0e4c78d0559cd6da653bf740f

eqbglqcngblqnl.bat

1fbdb97893d09d59575c3ef95df3c929fe6b6ddf1b273283e4efadf94cdc802d

safe.exe

5950b4e27554585123d7fca44e83169375c6001201e3bf26e57d079437e70bcd

safe.exe

7018240d67fd11847c7f9737eaaae45794b37a5c27ffd02beaacaf6ae13352b3

safe.exe

28e82f28d0b9eb6a53d22983e21a9505ada925ebb61382fabebd76b8c4acff7c

safe.exe

fc31043b5f079ce88385883668eeebba76a62f77954a960fb03bf46f47dbb066

DefenderControl.exe

a201f7f81277e28c0bdd680427b979aee70e42e8a98c67f11e7c83d02f8fe7ae

PRETTYOCEANApplicationdrs.bi

6992aaad3c47b938309fc1e6f37179eb51f028536f8afc02e4986312e29220c0

Setup.exe

510e9fa38a08d446189c34fe6125295f410b36f00aceb65e7b4508e9d7c4e1d1

WRSA.exe

ed0fd61bf82660a69f5bfe0e66457cfe56d66dd2b310e9e97657c37779aef65d

ghnhfglwaplf.bat

2155a029a024a2ffa4eff9108ac15c7db527ca1c8f89ccfd94cc3a70b77cfc57

nllraq.bat

251427c578eaa814f07037fbe6e388b3bc86ed3800d7887c9d24e7b94176e30d

ygariiwfenmqteiwcr.bat

3295f5029f9c9549a584fa13bc6c25520b4ff9a4b2feb1d9e935cc9e4e0f0924

bsfyqgqeauegwyfvtp.bat

6c9d8c577dddf9cc480f330617e263a6ee4461651b4dec1f7215bda77df911e7

rgibdcghzwpk.bat

84e1476c6b21531de62bbac67e52ab2ac14aa7a30f504ecf33e6b62aa33d1fe5

pxyicmajjlqrtgcnhi.bat

a80c7fe1f88cf24ad4c55910a9f2189f1eedad25d7d0fd53dbfe6bdd68912a84

evhgpp.bat

b998a8c15cc19c8c31c89b30f692a40b14d7a6c09233eb976c07f19a84eccb40

eqbglqcngblqnl.bat

1fbdb97893d09d59575c3ef95df3c929fe6b6ddf1b273283e4efadf94cdc802d

qesbdksdvnotrjnexutx.bat

0965cb8ee38adedd9ba06bdad9220a35890c2df0e4c78d0559cd6da653bf740f

HOW TO RESTORE YOUR FILES.TXT

 
Filenames with Associated SHA-1 Hashes

Filenames

SHA-1

safe.exe

c8a0060290715f266c89a21480fed08133ea2614
Commands Used by Snatch Threat Actors

Commands

wmiadap.exe /F /T /R

%windir%System32svchost.eve –k WerSvcGroup

conhost.exe 0xFFFFFFFF -ForceV1

vssadmin delete shadows /all /quiet

bcdedit.exe /set {current} safeboot minimal

REG ADD HKLMSYSTEMCurrentControlSetControlSafeBootMinimalVSS /VE /T REG_SZ /F /D Service

REG ADD HKLMSYSTEMCurrentControlSetControlSafeBootMinimalmXoRpcSsx /VE /T REG_SZ /F /D Service

REG QUERY HKLMSYSTEMCurrentControlSetControl /v SystemStartOptions

%CONHOST% “1088015358-1778111623-1306428145949291561678876491840500802412316031-33820320

“C:Program Files (x86)MicrosoftEdgeApplicationmsedge.exe” –flag-switches-begin –flag-switches-end –no-startup-window /prefetch:5

cmd /d /c cmd /d /c cmd /d /c start ” ” C:Usersgrade1AppDataLocalPRETTYOCEANluvApplicationPRETTYOCEANApplicationidf.bi.
Registry Keys

Registry Keys

HKLMSOFTWAREMicrosoftWindows Media Player NSS3.0ServersD8B548F0-E306-4B2B-BD82-25DAC3208786FriendlyName

HKUS-1-5-21-4270068108-2931534202-3907561125-1001SoftwareMicrosoftWindowsCurrentVersionShell ExtensionsCached{ED50FC29-B964-
48A9-AFB3-15EBB9B97F36} {ADD8BA80-002B-11D0-8F0F-00C04FD7D062} 0xFFFF
System Log Changes

Source

Message

TerminalServices-RemoteConnectionManager

Remote session from client name exceeded the maximum allowed failed logon attempts. The session was forcibly terminated.

Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall

A rule was added (Event 2004) or modified (Event 2005) in the Windows Defender Firewall exception list. All rules included action “Allow” and rule name included “File and Printer Sharing”

Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall

A Windows Defender Firewall setting was changed in private, public, and domain profile with type “Enable Windows Defender Firewall” and value of “no”.

Microsoft-Windows-TaskScheduler%4Operational

Instance of process C:Windowssvchost.exe. (Incorrect file location, should be C:WindowsSystem32svchost.exe)
Mutexes Created

Mutexes Created

Sessions1BaseNamedObjectsgcc-shmem-tdm2-fc_key

Sessions1BaseNamedObjectsgcc-shmem-tdm2-sjlj_once

Sessions1BaseNamedObjectsgcc-shmem-tdm2-use_fc_key

gcc-shmem-tdm2-fc_key

gcc-hmem-tdm2-sjlj_once

gcc-shmem-tdm2-use_fc_key

MITRE ATT&CK TACTICS AND TECHNIQUES

See Tables 4-16 for all referenced threat actor tactics and techniques in this advisory.

Table 4: Snatch Threat Actors ATT&CK Techniques for Enterprise – Reconnaissance

Technique Title

ID

Use

Gather Victim Network Information

T1590

Snatch threat actors may gather information about the victim’s networks that can be used during targeting.
Table 5: Snatch Threat Actors ATT&CK Techniques for Enterprise – Resource Development

Technique Title

ID

Use

Acquire Infrastructure: Virtual Private Server

T1583.003

Snatch threat actors may rent Virtual Private Servers (VPSs) that can be used during targeting. Snatch threat actors acquire infrastructure from VPS service providers that are known for renting VPSs with minimal registration information, allowing for more anonymous acquisitions of infrastructure.
Table 6: Snatch Threat Actors ATT&CK Techniques for Enterprise – Initial Access

Technique Title

ID

Use

Valid Accounts

T1078

Snatch threat actors use compromised user credentials from criminal forums/marketplaces to gain access and maintain persistence on a victim’s network.

External Remote Services

T1133

Snatch threat actors exploit weaknesses in RDP to perform brute forcing and gain administrator credentials for a victim’s network.

Snatch threat actors use VPN services to connect to a victim’s network.
Table 7: Snatch Threat Actors ATT&CK Techniques for Enterprise – Execution

Technique Title

ID

Use

Command and Scripting Interpreter: Windows Command Shell

T1059.003

Snatch threat actors may use batch files (.bat) during ransomware execution and data discovery.

System Services: Service Execution

T1569.002

Snatch threat actors may leverage various Windows tools to enumerate systems on the victim’s network. Snatch ransomware used sc.exe.
Table 8: Snatch Threat Actors ATT&CK Techniques for Enterprise – Persistence

Technique Title

ID

Use

Valid Accounts: Domain Accounts

T1078.002

Snatch threat actors compromise domain accounts to maintain persistence on a victim’s network.
Table 9: Snatch Threat Actors ATT&CK Techniques for Enterprise – Defense Evasion

Technique Title

ID

Use

Masquerading

T1036

Snatch threat actors have the ransomware executable match the SHA-256 hash of a legitimate file to avoid rule-based detection.

Indicator Removal: File Deletion

T1070.004

Snatch threat actors delete batch files from a victim’s filesystem once execution is complete.

Modify Registry

T1112

Snatch threat actors modify Windows Registry keys to aid in persistence and execution.

Impair Defenses: Disable or Modify Tools

T1562.001

Snatch threat actors have attempted to disable a system’s antivirus program to enable persistence and ransomware execution.

Impair Defenses: Safe Mode Boot

T1562.009

Snatch threat actors abuse Windows Safe Mode to circumvent detection by antivirus or endpoint protection and encrypt files when few services are running.
Table 10: Snatch Threat Actors ATT&CK Techniques for Enterprise – Credential Access

Technique Title

ID

Use

Brute Force: Password Guessing

T1110.001

Snatch threat actors use brute force to obtain administrator credentials for a victim’s network.
Table 11: Snatch Threat Actors ATT&CK Techniques for Enterprise – Discovery

Technique Title

ID

Use

Query Registry

T1012

Snatch threat actors may interact with the Windows Registry to gather information about the system, configuration, and installed software.

Process Discovery

T1057

Snatch threat actors search for information about running processes on a system.
Table 12: Snatch Threat Actors ATT&CK Techniques for Enterprise – Lateral Movement

Technique Title

ID

Use

Remote Services: Remote Desktop Protocol

T1021.001

Snatch threat actors may use Valid Accounts to log into a computer using the Remote Desktop Protocol.
Table 13: Snatch Threat Actors ATT&CK Techniques for Enterprise – Collection

Technique Title

ID

Use

Data from Local System

T1005

Snatch threat actors search systems to find files and folders of interest prior to exfiltration.
Table 14: Snatch Threat Actors ATT&CK Techniques for Enterprise – Command and Control

Technique Title

ID

Use

Application Layer Protocols: Web Protocols

T1071.001

Snatch threat actors establish connections over port 443 to blend C2 traffic in with other web traffic.
Table 15: Snatch Threat Actors ATT&CK Techniques for Enterprise – Exfiltration

Technique Title

ID

Use

Exfiltration

TA0010

Snatch threat actors use exfiltration techniques to steal data from a victim’s network.
Table 16: Snatch Threat Actors ATT&CK Techniques for Enterprise – Impact

Technique Title

ID

Use

Data Encrypted for Impact

T1486

Snatch threat actors encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources.

Inhibit System Recovery

T1490

Snatch threat actors delete all volume shadow copies from a victim’s filesystem to inhibit system recovery.

MITIGATIONS

These mitigations apply to all stakeholders. The authoring agencies recommend that software manufactures incorporate secure-by-design and -default principles and tactics into their software development practices for hardening software against ransomware attacks (e.g., to prevent threat actors from using Safe Mode to evade detection and file encryption), thus strengthening the secure posture for their customers.

For more information on secure by design, see CISA’s Secure by Design and Default webpage and joint guide.

The FBI and CISA recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the Snatch threat actor’s activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

  • Reduce threat of malicious actors using remote access tools by:
    • Auditing remote access tools on your network to identify currently used and/or authorized software.
    • Reviewing logs for execution of remote access software to detect abnormal use of programs running as a portable executable [CPG 2.T].
    • Using security software to detect instances of remote access software being loaded only in memory.
    • Requiring authorized remote access solutions to be used only from within your network over approved remote access solutions, such as virtual private networks (VPNs) or virtual desktop interfaces (VDIs).
    • Blocking both inbound and outbound connections on common remote access software ports and protocols at the network perimeter.
  • Implement application controls to manage and control execution of software, including allowlisting remote access programs.
    • Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
  • Strictly limit the use of RDP and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Disable command-line and scripting activities and permissions [CPG 2.N].
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 4.C].
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege (PoLP) [CPG 2.E].
  • Reduce the threat of credential compromise via the following:
    • Place domain admin accounts in the protected users’ group to prevent caching of password hashes locally.
    • Refrain from storing plaintext credentials in scripts.
  • Implement time-based access for accounts set at the admin level and higher [CPG 2.A, 2.E].

In addition, the authoring authorities of this CSA recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, and to reduce the impact and risk of compromise by ransomware or data extortion actors:

  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, the cloud).
  • Maintain offline backups of data and regularly maintain backup and restoration (daily or weekly at minimum). By instituting this practice, an organization limits the severity of disruption to its business practices [CPG 2.R].
  • Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with NIST’s standards for developing and managing password policies.
    • Use longer passwords consisting of at least eight characters and no more than 64 characters in length [CPG 2.B].
    • Store passwords in hashed format using industry-recognized password managers.
    • Add password user “salts” to shared login credentials.
    • Avoid reusing passwords [CPG 2.C].
    • Implement multiple failed login attempt account lockouts [CPG 2.G].
    • Disable password “hints.”
    • Refrain from requiring password changes more frequently than once per year.
      Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
    • Require administrator credentials to install software.
  • Require phishing-resistant multifactor authentication (MFA) for all services to the extent possible, particularly for webmail, virtual private networks (VPNs), and accounts that access critical systems [CPG 2.H].
  • Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement [CPG 2.F].
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic and activity, including lateral movement, on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host [CPG 3.A].
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.
  • Disable unused ports and protocols [CPG 2.V].
  • Consider adding an email banner to emails received from outside your organization [CPG 2.M].
  • Disable hyperlinks in received emails.
  • Ensure all backup data is encrypted, immutable (i.e., ensure backup data cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, FBI and CISA recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. FBI and CISA recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Tables 4-16).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

FBI and CISA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

REPORTING

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from IP addresses, a sample ransom note, communications with Snatch threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file. The FBI and CISA strongly discourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to the FBI Internet Crime Complaint Center (IC3) at ic3.gov, a local FBI Field Office, or to CISA at report@cisa.gov or (888) 282-0870.

REFERENCES

[1] DataBreaches.net

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. FBI and CISA do not endorse any commercial entity, product, or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by FBI or CISA.

VERSION HISTORY

September 20, 2023: Initial version.

Security

Internet Wide Multi VPN Search From Single /24 Network, (Mon, Sep 18th)

Leave a comment
This post was originally published on this site

Brute-forcing passwords for VPN access has become a standard technique for various actors to access corporate networks to exfiltrate data later or deploy ransomware. After identifying the VPN, an attacker may use simple brute forcing, credential stuffing, or social engineering in some very public cases to obtain access.

Today, I noticed in one of my honeypots new "most commonly hit" URLs:

GET /remote/login HTTP/1.1
GET /dana-na/auth/url_default/welcome.cgi HTTP/1.1
GET /global-protect/login.esp HTTP/1.1
GET /vpn/index.html HTTP/1.1

These URLs have one thing in common: They are used by VPN and remote access solutions. The first one is a bit generic, making it difficult to identify the exact product they are looking for.

The second URL, '/dana-na/' appears to be associated with Pulse Connect Security, a VPN solution with a rich history of vulnerabilities in the past. I do not see any exploit attempts as part of these scans, just simple requests for the URL. Some of our handlers suggested Juniper may also use it.

'/global-protect/login.esp' is associated with Palo Alto's Global Protect solution. It also had a few vulnerabilities in the past. 

Finally, '/vpn/index.html' appears to be related to a Netscaler remote access product.

Another interesting property of these scans is that they all originate from 77.105.147.0/24. A different IP address in this subnet scans for each URL; the IPs have not been used before the last couple of days.

Whois data for this network:

role:           Aeza Network
address:        350001, Krasnodar, st. im. Mayakovskogo, b. 160, office 2.4
nic-hdl:        AN32749-RIPE
mnt-by:         aeza-group-mnt
created:        2021-11-24T09:55:02Z
last-modified:  2021-11-24T09:55:02Z
source:         RIPE # Filtered

The scanning IP addresses have no services exposed, but other IPs in this /24 do have simple default web pages. This appears to be typical for a hosting provider like Aeza Networks. It is possible that the originator of these scans compromised or just rented a few servers in this subnet. Low-cost virtual servers offered by providers like Aeza, are always popular as "throw-away" systems to conduct scans like this.

What should you do?

First, ensure your remote access software is up to date. This should not just include these web-based VPN solutions. Include console servers or other remote access methods.

Secondly, use multi-factor authentication. If supported, opt for a phishing-resistant solution. Note that simple one-time passwords like Google Authenticator are not phishing-resistant. A phishing-resistant solution does not allow the user to select the credentials for a particular website. Possible solutions are FIDO2 or Passkeys, which are sadly not much seen yet for these types of remote access systems.

You should probably implement country-based blocking for critical gateways or a limited allow list. But quite often, you will need these VPN gateways to be accessible from dynamic home IPs, and country-based block lists are not only hard to get right, but they are simple to bypass. Blocking 77.105.147.0/24 may be a good start 🙂

And a bit of "security through obscurity" can help: Try to run these gateways on an unusual port.

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

DShield and qemu Sitting in a Tree: L-O-G-G-I-N-G, (Thu, Sep 14th)

Leave a comment
This post was originally published on this site

[This is a Guest Diary by Allen Ingle, an ISC intern as part of the SANS.edu BACS program]

Introduction

Setting up and configuring the DShield Honeypot is an important component of contributing to the SANS Internet Storm Center (ISC) [1]. The recommended OS and hardware for hosting the installation is Raspberry Pi OS Lite [2] on any of the Raspberry Pi hardware versions [3]. That said, for development work and experimentation, constantly re-installing the OS on the physical hardware isn’t the most convenient process and an additional expense for more Raspberry Pi’s isn’t exactly appealing either. Similarly, someone interested in dipping their toe in the honeypot waters might not want to commit to purchasing the Raspberry Pi hardware right away.

So, what is a cost effective and time-efficient solution that doesn’t require any additional hardware that takes advantage of native Windows functionality? This blog post details how to use qemu to accomplish exactly that.

Why the DShield Honeypot?

The DShield honeypot serves as a data collection point for the SANS ISC. In doing so, DShield deployments support the ISC’s aim to crowdsource monitoring of malicious activities online. However, as with many code repositories, issues crop up from time to time [4]. A few of the issues personally encountered include:

  • Minor issues with the install.sh setup script.
  • Data retention issues in the isc-agent/web honeypot.
  • Inability to access full web honeypot logs on the local system.
  • Compatibility quirks with Ubuntu Server 22.04.2 LTS.

Contributing to the DShield project serves not only the project itself but also the broader information security community. qemu, an open-source hardware emulator, provides a comprehensive solution for this, from the deployment of a DShield honeypot to troubleshooting and testing. Although qemu is most often associated with Linux environments, it can be seamlessly operated within Windows through the Windows Subsystem for Linux (WSL), making it a versatile tool for facilitating DShield honeypot deployment.

Getting Setup on Windows Subsystem for Linux (WSL)

For myself, the most pressing problem for troubleshooting encountered issues is overcoming limited hardware availability: having only a single Raspberry Pi 4B 8 GB, a time and cost-effective solution is needed. One such solution is to use WSL. WSL allows Linux applications and utilities to be run directly on Windows. In this case, it can also be used as the base for qemu installation. The online documentation can guide how to configure Ubuntu 22.04 LTS on WSL. [5] It can also be installed from the Microsoft Store. [6]


Figure 1: Ubuntu 22.04 LTS running on Windows 11 WSL

Upgrading and Configuring Ubuntu 22.04 LTS on WSL for qemu Support

Once Ubuntu 22.04 LTS is installed on the WSL, the operating system will need to be updated and specific packages installed to facilitate qemu operations, as well as prepare for subsequent setup tasks. Execute the following commands to achieve this:

sudo apt update -y && sudo apt upgrade -y # update the OS
sudo apt install -y qemu openssl qemu-utils fdisk qemu-system-arm bc # install packages

Executing these commands serves dual purposes: it updates the Ubuntu installation to the latest version, improving security, and it equips the system with essential tools for deploying and managing a DShield honeypot via qemu.

Investigating a qemu Solution

Already aware that qemu could provide hardware emulation but not certain if it would accomplish the task or how to implement it, research was initiated to see if this trail had already been blazed.

Early research identified two major leads:

  1. Raspberry Pi 3B qemu Built-in Support: qemu has a built-in machine configuration for a variety of Raspberry Pi boards up to 3B. [7]
  2. Raspberry Pi 3B qemu Configuration: Radu Zaharia has an excellent post detailing some of the configuration options when implementing qemu to emulate Raspberry Pi 3B hardware. [8]

Obtaining the Latest Raspberry Pi OS Lite (ARM) Disk Image

Equipped with this information, the next step is to download the latest version of Raspberry Pi OS Lite:

Commands Notes 
mkdir ~/rpi && cd ~/rpi
 create a directory named ‘rpi’ and change to it 
wget -q --show-progress https://downloads.raspberrypi.org/raspios_lite_armhf_latest -O raspios_lite_armhf_latest.img.xz
 download the latest Raspberry Pi OS Lite image for arm architectures 
xz --decompress ./ raspios_lite_armhf_latest.img.xz
 decompress the image 
cp raspios_lite_armhf_latest.img.xz rpi-16g.img
 make a working copy

Command Table 1: Download & extract Raspberry Pi OS Lite (armhf)

 


Figure 2: Downloading with 'wget'

 

Resizing and Mounting the Disk Image with a Calculated Offset

Next, the image file must be resized and mounted. The offset of the first partition in the image file will also need to be calculated in order to mount the image correctly.

Commands Notes 
qemu-img resize ./rpi-16g.img 16G
 resize the .img file 
fdisk -l ./rpi-16g.img
 calculate the offset based on the start of the first partition 
sudo mkdir /mnt/rpi
create a directory to mount to 
sudo mount -o loop,offset=4194304 ./rpi-16g.img /mnt/rpi
mount the .img using the offset we calculated

Command Table 2: Resize and mount the .img file

 


Figure 3: Calculating the offset with ‘bc’

 

Creating a ‘userconf’ File to Enable Login

To log in after booting, a ‘userconf’ file should be created in the appropriate directory on the mounted image.

Commands Notes 
echo 'pi' | openssl passwd -6 -stdin
 generates a SHA-512 hashed password out of ‘pi’ 
sudo nano /mnt/rpi/userconf
creates the userconf file

Command Table 3: Generate a 'userconf' file and populate it with credentials

The following string, when placed in the ‘userconf’ file, will create the user ‘pi’ with password ‘pi’

pi:$6$/0QsZLLqVv.MTT9N$jUbZ6jl14gI1EEMhE8jHmiyZf5CF4ggZDwzmW1oV/e/92F7MPqOPgFW6JBs6coPsk94IMjZIyW4K21wRsM0Qb1

Note: The use of the username ‘pi’ and password ‘pi’ is for demonstration purposes only. These credentials are commonly targeted by attackers and should not be used in a production environment. [9]

First Boot!

With that done, it’s time for the first boot by executing the following:

qemu-system-aarch64 
   -machine raspi3b 
   -cpu cortex-a72 
   -dtb /mnt/rpi/bcm2710-rpi-3-b-plus.dtb 
   -m 1G -smp 4 
   -kernel /mnt/rpi/kernel8.img 
   -sd ~/rpi/rpi-16g.img 
   -nographic 
   -device usb-net,netdev=net0 
   -netdev user,id=net0,hostfwd=tcp::2222-:2222,hostfwd=tcp::2223-:2223,hostfwd=tcp::8000-:8000 
   -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1"

 

Option Explanation 
-machine raspi3b
Sets the emulated machine to Raspberry Pi 3 Model B. 
-cpu cortex-a72
 Sets the CPU model to Cortex-A72. 
-dtb /mnt/rpi/bcm2710-rpi-3-b-plus.dtb
 Path to the Device Tree Blob (DTB) file (part of the mounted image) 
-m 1G
 Allocates 1 GB of RAM to the machine. 
-smp 4
 Sets the number of CPU cores to 4. 
-kernel /mnt/rpi/kernel8.img
 Path to the kernel image. 
-sd ./rpi-16g.img
 Specifies the SD card image to be used. 
-nographic
 Disables graphical output, uses terminal instead. 
-device usb-net,netdev=net0
 Adds a USB network device with the specified netdev backend. 
-netdev user,id=net0,hostfwd=tcp::2222-:2222,hostfwd=tcp::2223-:2223,hostfwd=tcp::8000-:8000
 Creates a user-mode network backend with port forwarding from our host (Windows) to our guest (DShield) through qemu for the specified ports: 2222, 2223, and 8000 (needed for DShield). 
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1"
Kernel command line options. (Needed to boot at all)

Command Table 4: Explanation of qemu options

 

Resize the Raspberry Pi Disk and File System

Recall that the size of the image file has already been changed to 16GB, but now the OS will need to update its disk and file system to take advantage of the additional space. This requires rebooting the emulated device but it is recommended to shut it down instead. Issuing a reboot to the Raspberry Pi OS tends cause qemu to hang.

Commands Notes
df -h  check the size of /dev/root
sudo fdisk -l  get the starting offset of the second partition (532480)
sudo fdisk /dev/mmcblk0 enter the fdisk utility
# d, 2
# c, n, p, 2, 532480, <enter>, n
# w    		 options to enter into the fdisk utility
sudo shutdown now shut down the emulated device
# You are now back at the WSL prompt. Up arrow until at the qemu command previously used to launch your emulated Raspberry Pi device and execute it to boot again.
df -h; sudo resize2fs /dev/mmcblk0p2; df -h command sequence to check, resize, and verify the filesystem
sudo shutdown now shut down the emulated device
# You are now back at the WSL prompt. Up arrow until at the qemu command previously used to launch your emulated Raspberry Pi device and execute it to boot again.

Command Table 5: Resize the Raspberry Pi OS Lite disk & update the file system to show the full 16GB

After successfully executing the commands above, the device should have a configuration similar to this:

 


Figure 4: After updating the disk and file system, /dev/root shows 16G as the size

 

Update the Raspberry Pi and Check the Kernel Version

At this point, there is plenty of disk space to update the device and upgrade it, if needed. Use the following one-liner to accomplish this:

Commands Description 
sudo apt update -y && sudo apt dist-upgrade -y && sudo apt autoremove -y && sudo apt clean -y && sudo apt autoclean -y
 Update, upgrade, and clean the system

Command Table 6: Commands to update the Raspberry Pi OS

 

DONT SHUTDOWN/REBOOT YET!

The qemu command used to initiate the emulated Raspberry Pi specifies a kernel image file with the “-kernel /mnt/rpi/kernel8.img” option. When updating and upgrading the installation, the kernel image located at “/mnt/rpi/kernel8.img” will not be updated automatically. This can result in issues with the emulated Raspberry Pi's functionality.

Execute the following on your emulated Raspberry Pi BEFORE shutting down to provide a URL for downloading an updated kernel8.img file. Copy the URL and then shutdown the Raspberry Pi device.

# On the Raspberry Pi BEFORE Shutting Down
KVER=$(dpkg -s raspberrypi-kernel | grep Version | awk '{print $2}' | cut -d':' -f2 | cut -d'-' -f1); 
echo "https://github.com/raspberrypi/firmware/raw/$KVER/boot/kernel8.img"

 


Figure 5: Copy the URL to download the correct kernel8.img directly from the Raspberry Pi repo

 

# Copy the URL echoed out and shut down the Raspberry Pi
sudo shutdown now

# Back on your WSL prompt
sudo wget -q --show-progress <COPIED URL GOES HERE> -O /mnt/rpi/kernel8.img

 

Install DShield

DShield can now be installed by following the guidance on the official GitHub repository for Raspberry Pi [10] or using the commands below. Be sure to obtain an API key by creating an account at the Internet Storm Center [11]. It is needed during installation and, later, to contribute logs to the DShield project.

# Enable SSH
sudo systemctl enable ssh; sudo systemctl start ssh

# Install DShield
sudo apt -y install git
git clone https://github.com/DShield-ISC/dshield
cd dshield/bin
sudo ./install.sh

 

L-O-G-G-I-N-G

At this stage, the qemu-emulated Raspberry Pi is operational with the DShield Honeypot installed and it is nearly to the point of aggregating logs. The next critical step involves enabling external access to the honeypot. This requires strategically configuring the network perimeter device, be it a router, firewall, or other security appliance, to route inbound traffic from your public IP address to the relevant listening ports on the Windows host machine.

Before diving into the specifics of configuring the Windows Firewall, lets first discuss the path that incoming malicious traffic will follow. Using the "hostfwd" parameter in the qemu command string, wslrelay.exe (on WSL) will create corresponding listeners on the Windows host, setting the stage for the subsequent forwarding of traffic.

 


Figure 6: Attack SSH traffic forwarded to port 2222, through the Windows Firewall, and on to the wslrelay.exe listeners

 

Any traffic that hits those ports will be forwarded via wslrelay.exe from the Windows host (Ubuntu on WSL) to the Raspberry Pi OS guest (DShield on Raspberry Pi OS).

 


Figure 7: Inside the wsl environment, qemu forwards the SSH traffic from host to guest where DShield is listening

 

In the example depicted above, the qemu configuration implemented is based on the following "hostfwd" parameter:

hostfwd=tcp::2222-:2222

From here, the Cowrie SSH honeypot will take over and log the malicious traffic in the Cowrie logs.

If that seems complicated, no worries! These processes are automated through the initial execution of the qemu command string and the establishment of corresponding Windows Firewall rules that permit incoming traffic on the specified ports.

Configure the Windows Firewall – Adding Rules

Before configuring the Windows Firewall, take stock of what is about to happen. This will intentionally poke a hole in the Windows host’s firewall to allow malicious traffic in. The firewall rules below will remain up until intentionally taken back down.

If this is an acceptable risk, then let’s carry on!

The following must be run in a command prompt with Administrator privileges:

netsh advfirewall firewall add rule name="DShield SSH" dir=in action=allow protocol=TCP localport=2222
netsh advfirewall firewall add rule name="DShield Telnet" dir=in action=allow protocol=TCP localport=2223
netsh advfirewall firewall add rule name="DShield Web" dir=in action=allow protocol=TCP localport=8000

These rules will allow traffic through the Windows firewall where qemu should already be running and wslrelay.exe will be listening.

 


Figure 8: wslrelay.exe listening on the same ports that are now exposed

 

It will then be picked up by the corresponding ports on your DShield honeypot.

 


Figure 9: The DShield honeypot listening on those ports inside the qemu environment

 

Configure the Windows Firewall – Removing Rules

To remove the firewall rules, the following must be run in a command prompt with Administrator privileges:

netsh advfirewall firewall delete rule name="DShield SSH" protocol=TCP localport=2222
netsh advfirewall firewall delete rule name="DShield Telnet" protocol=TCP localport=2223
netsh advfirewall firewall delete rule name="DShield Web" protocol=TCP localport=8000

These rules should be removed before you shut down your honeypot.

Security Considerations

For a more robust and secure DShield honeypot setup, the following best practices are recommended. Compatibility with specific hardware, BIOS, and system configurations should be verified through testing.

  • QEMU Sandboxing: Utilize the ‘-sandbox on’ flag in qemu to restrict system calls and enhance security.
  • Resource Limitation: Set CPU and memory limits for the guest VM to mitigate resource exhaustion attacks.
    • This configuration sets ‘-smp 4 -m 1G’ to allocate four CPU cores and 1 GB of RAM.
  • Port Forwarding: Forward only essential ports required for DShield functionality.
  • Network Segmentation: Place the host machine on a separate network or VLAN to isolate it.
  • Software Updates: Apply updates to both Windows and Ubuntu and use the latest DShield version.
  • SSH Security for DShield: Enable key-based authentication and disable root login when using SSH to access DShield honeypot logs.

At the end of the day, there will always be risk when running a honeypot on any network, much less poking a hole in the firewall. Ensure these risks fit well within the risk profile used for operating on any personally owned devices or networks.

Alternatives for Accomplishing Similar Results

This isn’t the only means of virtualizing a DShield honeypot. The following alternatives were explored, and some were even implemented, but running it locally, inside qemu, has proven to be the most representative of the recommend installation without additional Raspberry Pi hardware.

  • Virtual Machines: These offer a convenient option for running a DShield honeypot on Ubuntu 22.04 LTS [12] but lacks support for the recommended Raspberry Pi OS Lite or the ability to emulate ARM-based hardware.

 


Figure 10: DShield on Ubuntu 22.04 LTS running in a VM

 

  • WSL: The Windows Subsystem for Linux is an easier option for using Ubuntu 22.04 LTS to set up a DShield honeypot but suffers from the same lack of support for testing and troubleshooting Raspberry Pi OS Lite on emulated ARM-based hardware. [13]

 


Figure 11: Ubuntu 22.04 LTS running in WSL

 

  • qemu: Offers hardware emulation and supports running the latest versions of the recommended operating system. [14]
  • Docker Containers: Containers can replicate the software environment needed for DShield but lack hardware emulation capabilities. Additionally, existing solutions are dated. [15]
  • Cloud-based Virtualization: Some cloud services offer ARM-based virtual machines. However, the additional costs can still be a drawback. [16]

What Is the Question Being Answered?

  • What is a cost effective and time-efficient way to set up additional DShield honeypots without requiring any additional physical hardware?

Who Would Benefit from This Information and Why?

  • Cybersecurity Researchers: Students and professionals focused on cybersecurity could utilize this information to effectively set up virtual honeypots. This provides them with a budget-friendly, scalable alternative to physical honeypots, thereby accelerating their research efforts.
  • Software Developers: Those constrained by hardware limitations can benefit immensely from leveraging qemu. This tool allows them to emulate the specific hardware features of multiple Raspberry Pi devices by aiding in testing and development without hardware limitations or supply concerns. [17]
  • SANS BACS Interns: Students participating in the SANS BACS internship program would find this information invaluable. It offers a way to rapidly deploy a honeypot without the need for purchasing and configuring hardware, allowing them to focus more on the core elements of their internship tasks.

Conclusion

This blog post provides an in-depth guide on how to deploy a DShield Honeypot using qemu on a Windows system with the Windows Subsystem for Linux (WSL). This approach offers a cost-effective and time-efficient way to contribute to the SANS ISC without needing to invest in additional hardware like a Raspberry Pi. By leveraging qemu's hardware emulation capabilities, this guide details the entire process, from setting up the initial environment, to resolving issues with kernel updates, and even configuring the Windows Firewall for data collection.

This strategy makes it easier to test, troubleshoot, and deploy DShield honeypots, and, in doing so, aid the broader cybersecurity community in gathering essential data about online threats. Whether you are a seasoned cybersecurity professional or a beginner interested in honing your skills, this qemu-based DShield honeypot deployment strategy offers an accessible pathway to contributing valuable data to the SANS ISC.

References

[1] https://www.dshield.org/tools/honeypot/
[2] https://github.com/DShield-ISC/dshield/blob/main/docs/install-instructions/Raspbian.md
[3] https://isc.sans.edu/diary/22680/
[4] https://github.com/DShield-ISC/dshield/issues
[5] https://learn.microsoft.com/en-us/windows/wsl/install
[6] https://apps.microsoft.com/store/detail/ubuntu-22042-lts/9PN20MSR04DW
[7] https://www.qemu.org/docs/master/system/arm/raspi.html
[8] https://raduzaharia.medium.com/system-emulation-using-qemu-raspberry-pi-3-4973260ffb3e
[9] https://tehtris.com/en/blog/our-selection-of-alerts-on-honeypots-report-9-may-2023
[10] https://github.com/DShield-ISC/dshield
[11] https://isc.sans.edu/register.html
[12] https://github.com/DShield-ISC/dshield/blob/main/docs/install-instructions/Ubuntu.md
[13] https://raspberrypi.stackexchange.com/questions/135262/how-to-install-raspberrypios-on-wsl
[14] https://www.qemu.org/docs/master/system/arm/raspi.html
[15] https://github.com/xme/dshield-docker
[16] https://www.mythic-beasts.com/order/rpi
[17] https://www.tomshardware.com/news/raspberry-pi-4-supply-issues

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Apple fixes 0-Day Vulnerability in Older Operating Systems, (Mon, Sep 11th)

Leave a comment
This post was originally published on this site

This update fixes the ImageIO vulnerability Apple patched for current operating systems last week. Now, Apple follows up with a patch for its older, but still supported, operating system versions.

According to Citizen Lab, this vulnerability is already being exploited. Exploitation took advantage of the ImageIO vulnerability and a vulnerability in the Apple wallet "PassKit" API to send a "Pass" to the victim, including the malicious image. These older operating systems support PassKit, but it needs to be clarified if they are vulnerable to the PassKit issue.

More details: Apple: https://support.apple.com/en-us/HT201222

Citizen Lab: https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/

 

iOS 15.7.9 and iPadOS 15.7.9 macOS Monterey 12.6.9 macOS Big Sur 11.7.10
CVE-2023-41064 [critical] ChatGPT-CVSS: 9 *** EXPLOITED *** ImageIO
A buffer overflow issue was addressed with improved memory handling.
Processing a maliciously crafted image may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
x x x

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Quickie: Generating a YARA Rule to Detect Obfuscated Strings, (Sun, Sep 10th)

Leave a comment
This post was originally published on this site

In diary entry "Creating a YARA Rule to Detect Obfuscated Strings" I explain how to tune a YARA rule with regular expressions for performance.

I'm sharing here a Python script I wrote to generate regular expressions. The script takes one argument: the string to BASE64 encode and generate regexes for (string "ActiveMime" in my previous diary entry):

#20230829
import base64
import itertools
import sys

def GenerateRegex(word):
    strings = []
    whitespace = [' ', 't', 'r', 'n']
    detect = word[:len(word) // 3 * 3]
    print(f'String to search: {word}')
    print(f'String to search (* 3): {detect}')
    detectBASE64 = base64.standard_b64encode(detect.encode('utf8')).decode('latin')
    print(f'BASE64 string to search: {detectBASE64}')
    whitespaceregex = '[' + ''.join(whitespace) + ']*'
    print(f'Whitespace characters: {whitespaceregex}')

    detectBASE64 = [char for char in detectBASE64]

    strings.append(whitespaceregex.join(detectBASE64))

    for ws in itertools.product(whitespace, whitespace):
        strings.append(detectBASE64[0] + ''.join(ws) + whitespaceregex.join([''] + detectBASE64[1:]))
    
    for ws1 in whitespace:
        strings.append(''.join(detectBASE64[0:2]) + ws1 + whitespaceregex.join([''] + detectBASE64[2:]))
    
    strings.append(''.join(detectBASE64[0:3]) + whitespaceregex.join([''] + detectBASE64[3:]))

    return strings, detect


def Main():
    regexStrings, detect = GenerateRegex(sys.argv[1])

    print('        $base64_%s%d = /%s/' % (detect, 0, regexStrings[0]))
    print()
    for index, regex in enumerate(regexStrings[1:]):
        print('        $base64_%s%d = /%s/' % (detect, index + 1, regex))

if __name__ == '__main__':
    Main()

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.