FAQ about Detection and Response

Does Rootkit alerting support real-time detection?

No.

Security Center uses scheduled tasks to scan memory for Rootkit threats. If a Rootkit threat is detected, a Rootkit alert is generated. For more information about Rootkit detection, see Detect Linux Rootkit intrusion threats.

How do I determine whether an asset is threatened by crypto-mining?

If the CPU usage of your server is significantly high, for example, reaching 80% or above, and unknown processes are continuously sending network packets outbound, you can determine that a crypto-mining threat exists on your server.

When an asset protected by Security Center is compromised by a crypto-mining program, Security Center sends an alert SMS or email to you. You can navigate to the Alert page and go to the CWPP tab to handle the crypto-mining alert. If the crypto-mining program is associated with other alert events, such as mining pool communication or malicious domain access, we recommend that you handle those associated alerts together. For more information about how to view and handle associated alerts, see Respond to security alerts.

Virus interception is not enabled and my server is under a crypto-mining attack. What do I do?

You can follow these steps to handle the crypto-mining alert and enable the Malicious Host Behavior Prevention capability.

1. Log on to Security Center console.

2. In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

3. On the Alert page, go to the CWPP tab, locate the corresponding alert, and click Actions in the Process column.

4. In the Crypto-mining program - Malicious software dialog box, select Virus Detection and Removal.

5. Click Handle Now to complete the handling of the crypto-mining alert event.

6. In the left-side navigation pane, choose System Configuration > Feature Settings. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

7. On the System Configuration page, go to the Settings tab and then the Protection Settings subtab. In the Proactive Defense section, turn on the Malicious Host Behavior Prevention switch to enable the virus interception feature.

I accidentally added a crypto-mining alert to the whitelist. How do I remove it?

1. Log on to Security Center console.

2. In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

3. On the Alert page, go to the CWPP tab and change the filter condition to Handled to view all handled alerts.

4. Locate the corresponding alert and click Remove from Whitelist in the Actions column to restore the alert.

How do I verify that automatic virus interception is in effect?

Log on to Security Center console. After you enable the Malicious Host Behavior Prevention feature on the System Configuration page, In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland. on the Alert page, go to the CWPP tab and click Precise Defense. If the defense status of the filtered alerts is Blocked, automatic virus interception is in effect.

How does Security Center detect hacker intrusion behaviors?

All hacker intrusion behaviors detected by Security Center are identified through scanning detection and verified by Alibaba Cloud security engineers after analyzing customer traffic data.

What are the common hacker intrusion behaviors?

The alert detection items provided by Security Center cover common hacker intrusion behaviors, including backdoors, brute-force attacks, and crypto-mining. For more information, see CWPP security alerts.

Why does phpinfo generate an alert? Is it a false positive?

No, it is not a false positive.

phpinfo contains a large amount of sensitive information, such as the absolute path of the website, which poses a high risk and may be exploited by hackers. Most hackers upload phpinfo as the first step to gather more information for further penetration. If you confirm that this file is a normal file required by your business, you can perform the following operations:

1. Log on to Security Center console.

2. In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

3. On the Alert page, go to the CWPP tab and select Add to Whitelist when handling the alert.

Does Security Center automatically isolate WebShell files?

No. Because WebShell files may contain information related to your business, you need to manually isolate them after evaluation. Isolated files can be found in the Quarantine folder and can be restored within 30 days. For more information about the Quarantine folder, see Respond to security alerts.

How does Security Center detect WebShells?

Security Center uses the following scanning methods to detect website script files of types such as PHP, ASP, and JSP.

• Disk scanning: When a file is uploaded to or downloaded to a server and a disk write behavior is detected, the file is scanned. If a malicious file is found, an alert is reported.

• Real-time monitoring of web directories.

• Scheduled scanning of web directories.

What objects can be added to the whitelist for security alerts?

The security alert handling feature allows you to add objects to the whitelist for alerts of the malicious software type. The whitelist operation only applies to the access source in the current alert event. The following alert types support being added to the whitelist:

Why are some alerts marked as Expired?

If more than 30 days have passed since the last occurrence of an alert, Security Center marks the alert status as Expired. If the alert is detected again, Security Center updates the alert occurrence time to the latest detection time and sets the alert status to Unhandled.

Why is the first occurrence time of a suspicious domain access alert inconsistent with the detection time?

When Security Center receives DNS resolution data, it needs to use algorithms to analyze and process the data. The DNS resolution data itself also has a certain delay. Therefore, the first occurrence time of a suspicious domain access alert is later than the detection time. A time difference of up to 5 hours is normal.

How does the unusual logon detection and alerting feature of Security Center work?

After you install the Security Center agent on your server, the unusual logon feature can detect logon behaviors on your server and generate alerts for logons from unusual locations. On Security Center console the Alert page, go to the CWPP tab to view alerts related to unusual server logons.

The Security Center agent periodically collects logon logs from your server and uploads them to the cloud for analysis and matching. If a successful logon event is detected from an unusual location, unusual IP, unusual time, or unusual account, an alert is triggered. The following content describes how different IP logon behaviors are determined:

• When Security Center is first applied to your server, no alerts are triggered during this period because no usual logon location is configured for the server.

• When a public IP successfully logs on to the server for the first time, Security Center records the location of that IP as a usual logon location and marks all public logon locations within the next 24 hours from that point as usual logon locations. After 24 hours, any logon behavior from a location not in the list of usual logon locations is considered a remote logon and an alert is generated.

• When an IP is determined to have a remote logon behavior, only the first logon behavior triggers an SMS alert. If the same IP successfully logs on 6 or more times, Security Center automatically records that IP location as a usual logon location.

  Note

  Remote logon alerts only apply to public IPs.

The following describes the alert policy for unusual logon IPs:

• Security Center sends an SMS alert for the first logon behavior from a remote IP. If that IP continues to log on, alerts are generated only in the console until the IP logs on 6 times and is automatically recorded as a usual logon location.

• If you use Security Center Advanced, Enterprise, or Ultimate edition, you can configure usual logon locations, usual logon IPs, usual logon times, and usual logon accounts for your servers. Alerts are generated for logon behaviors outside these custom rules. Your custom logon rules take precedence over the remote logon determination.

What unusual logon alerts does Security Center support?

The following unusual logon alert detection items are supported:

• Malicious IP logon (server, FTP application, MySQL, SQL Server, and more)

• Backdoor account logon

• Weak password account logon

• Suspected outbound logon scanning activity

• Unusual location logon

• Unusual account logon

• ECS brute-force attack success (multiple invalid users, RDP, SSH)

• Abnormal command sequence after ECS logon (SSH)

• ECS logon from unusual time, location, account, or IP

For more information about the detection principles of the preceding alert detection items, see Security alert detection items.

How do I avoid unusual logon alerts when logging on to the server normally?

You can use the Common Logon Management feature in Security Center console Protection Configuration > Host Protection > Host-specific Rule Management to configure usual logon locations, logon IPs, logon times, and accounts. This supports alerting for exceptional logon behaviors. It supports manually adding and automatically updating usual logon locations to alert on remote logon behaviors for specified assets.

What should I do if I accidentally triggered an ECS brute-force logon alert?

If your server password has high complexity, you may enter the wrong ECS server logon password multiple times before successfully logging on. This behavior is determined by the brute-force prevention model of Security Center as a brute-force attack on the ECS password, generating an ECS brute-force logon alert. After you confirm that the alert was triggered by a misoperation, you can ignore the alert. For more information about how to ignore an alert, see Respond to security alerts.

I configured a usual IP, time, and account but still receive unusual logon alerts during normal logon. What should I do?

In this case, first determine whether the alert type is an unauthorized IP logon, unusual location logon, or unusual account logon. Logon IP, logon location, account, and time are all factors that affect logon alerts. There is no priority among them. An alert is triggered as long as any one of these factors is abnormal.

When an unusual logon alert is generated, was the logon successful or blocked?

An unusual logon alert indicates that the logon was successful, but the logon behavior was determined as suspicious by Security Center, so a suspicious behavior alert event was generated.

What should I do if I confirm that an unusual logon alert is from a hacker?

1. Log on to Security Center console. In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

2. On the Alert page, go to the CWPP tab, locate the alert, and click Handle in the Actions column. Select Block for 12 hours and click Handle Now to immediately block the hacker intrusion. We recommend that you change your password immediately and check the server for any other unknown accounts and unknown public keys to prevent SSH password-free logon.

When an "Abnormal command sequence after ECS logon (SSH)" alert is generated, has the command already been executed?

Yes, the command has already been executed. Please promptly update your server logon password and check the server for any other unusual behaviors, such as unknown processes running.

What logs should I check on the server when an unusual logon alert occurs?

You can check the information in the /var/log/secure directory on the server. For example, run the command grep 10.80.22.22 /var/log/secure.

How do I view the number of brute-force attacks or interception status on my server?

Log on to Security Center console. In the left-side navigation pane, choose Detection and Response > Alert In the Network Defense Alert section, you can view information about successfully intercepted SSH brute-force attacks.

How do I prevent brute-force attacks on my server?

You can configure a usual logon IP or use certificate-based logon to prevent this situation. For more information about how to configure a usual logon IP, see Configure alert scan scope and handling rules.

Does brute-force prevention support protecting web applications or websites?

No.

Brute-force prevention protects servers that use the RDP and SSH protocols for logon. It does not support protecting web applications or websites.

What should I do after a brute-force attack succeeds?

If your server password has been successfully cracked by a brute-force attack, the attacker may have already compromised your server and left malicious programs. You can Log on to Security Center console. In the left-side navigation pane, choose Detection and Response > Alerts. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland. on the Alert page, go to the CWPP tab to check whether any brute-force success-related alerts exist.

If alerts similar to ECS brute-force attack success exist in your assets, it indicates that the corresponding server has been successfully brute-forced. We recommend that you harden your server security by following these steps as soon as possible:

• Handle brute-force success-related alerts

  On the Alert page, go to the CWPP tab, click Handle in the Actions column of the alert, select Block on the Alert page, and then click Handle Now. Security Center generates security group defense rules to block access from malicious IPs. For more information, see Respond to security alerts.

• Change the server user password

  Change the compromised user password as soon as possible. We recommend that you use a strong password.

• Use the baseline check feature of Security Center for risk detection

  Use the baseline check feature of Security Center to comprehensively check your server security and handle risk items based on the recommendations. For more information about how to enable this feature, see Enable the baseline risk check feature.

Why do I still receive password brute-force alerts after changing a weak password?

The changed weak password takes effect on a T+1 basis. During the period before the change takes effect, Security Center continues to report password brute-force alerts. For example, if you change the logon password at 10:00 on January 15, 2023, the baseline detection model collects the updated password information and updates the weak password database around 24:00 on that day. The unusual logon detection model loads the previous password from the weak password database before 24:00 on January 15, 2023, so password brute-force alerts still exist during this period.

You can ignore the alert after you confirm that you have changed the weak password and the baseline check does not detect weak password risks.

If your server logon password has been brute-forced, we recommend that you promptly harden the security of your server. For more information, see What should I do after a brute-force attack succeeds?.

Why are there still brute-force attack records for RDP even though the RDP port 3389 is already blocked by security group or firewall rules?

Due to the Windows logon auditing mechanism, the logon audit processes for the $IPC, RDP, and SAMBA services are recorded in the same log without distinguishing the specific logon method. Therefore, if you have already blocked the RDP service port but still see RDP brute-force attack records, you need to check whether the other two services are also enabled.

To check, verify whether the ECS instance is listening on ports such as 135, 139, and 445 and whether the public IP can access them. Also check whether there are corresponding logon records in the Windows security logs during that period.

Does ECS logon weak password refer to system-level RDP or SSH scanning?

Weak passwords include two types: weak passwords for RDP and SSH, and weak passwords for admin backend logons of systems such as CMS.

Which products provide data for the Attack Analysis page?

The data displayed on the Attack Analysis page is the attack statistics collected after Security Center automatically identifies and intercepts basic attack events, as well as attack data from Alibaba Cloud Web Application Firewall. This attack data covers cloud assets protected by Security Center and Web Application Firewall. You can view which assets are protected by Security Center on the Assets page.

What do I do if my Windows server continuously receives virus alerts?

• If your Windows server continuously receives virus alerts, we recommend that you first determine whether it is a false positive.

• If the virus file path is located in a Windows system hidden directory (such as the $Recycle.Bin Recycle Bin directory), you may not be able to directly search for this path in the file system. You need to enable the display of hidden files and system files as an administrator to view them. The Security Center agent obtains the file path through low-level scanning, which is not restricted by file system visibility.

• If you confirm that the alert is a false positive or the file has been cleared, refer to the whitelist removal operations in this document similar to I accidentally added a crypto-mining alert to the whitelist. How do I remove it?, or simply ignore the alert.

What do I do if I do not receive an alert when logging on from an unusual location or IP after configuring a usual logon rule?

If you have configured a usual logon location, usual logon IP, usual logon time, or usual logon account but do not receive the expected alert when logging on from an unusual location or IP, we recommend that you check the following:

• Check whether the rule is in effect. Newly added usual logon rules may take some time to take effect. Please wait patiently.

• Check whether the alert notification method is properly configured. Verify that your SMS and email notification settings are enabled.

• Check whether the server that triggered the logon is within the scope of the rule.

• On the Alert page, go to the CWPP tab and change the filter condition to Handled to check for any handled alert records.

I found a suspected decoy file (such as !~readme.txt in the .aegis directory) on my server. Does this mean the server is compromised?

/root/.aegis/!~readme.txt is a decoy file proactively deployed by Security Center to detect ransomware behavior. When ransomware attempts to encrypt this file, Security Center captures the behavior and triggers an anti-ransomware alert.

This file is a normal security protection file and is not a sign of server compromise. It does not affect the normal operation of the server. Do not delete it.

When handling an alert, only Add to Whitelist and Ignore options are available. The End Process and Virus Removal options are missing. What should I do?

Some alerts only have the Add to Whitelist and Ignore This Time options, without the Terminate Process and Virus Detection and Removal options. This usually occurs for the following reasons:

• You have not activated a paid edition of Security Center.

• This type of alert does not support Terminate Process and Virus Detection and Removal.

• The alert is historical data or an expired alert event.

How do I determine whether an alert is triggered by an Alibaba Cloud official scanner or verify the source of an alert SMS?

• Determination method

  Check the source IP address in the alert details. If the source IP belongs to the official Security Center scanning IP range (for example, 47.110.180.32/27), it is confirmed as a normal scanning behavior triggered by official services. If the IP is not within this range, it is not an official service call. We recommend that you verify whether it is used by your business or a third-party tool, or check whether there is an AccessKey leak risk.

• SMS source verification

  If you receive a suspected Security Center alert SMS but there is no corresponding alert in the console, or you suspect the authenticity of the SMS, you should verify it by checking the SMS sender number and the actual alert records in the console. If there are no related security events in the console and no AccessKey leak is detected for your account, it can usually be determined that the SMS is not from the Security Center of your account (it may be a false positive, another product, or a phishing SMS). We recommend that you refer to the actual data in the console.

Why is the number of network defense alerts in Security Center inconsistent with the interception records in Cloud Firewall?

The main reasons for the data discrepancy between the two are as follows:

• Different statistical scopes: Cloud Firewall counts all network-layer interception events (including ACL policies, IPS intrusion prevention, etc.), while Security Center focuses only on specific security threats (such as SSH brute-force attacks and web application attacks).

• Different data aggregation mechanisms: Security Center aggregates multiple attacks initiated by the same source IP within a short period for display (merged into one alert), while Cloud Firewall typically records each independent interception log.

• Time windows and delays: The time ranges selected in the two consoles may differ, and there is also a certain synchronization delay in Security Center data processing.

Are server resources deleted or shut down after Security Center generates an alert?

No.

What should I do if handling a suspicious process is ineffective or only Add to Whitelist/Ignore options are available?

Cause

You have not activated a paid edition of Security Center, or the process corresponding to the alert is no longer running or the file has been deleted.

Solution

• Activate the Advanced edition or above to use automatic handling features.

• If you do not activate a paid edition, you need to manually handle the issue by logging on to the server:

  1. Record the process ID (PID) in the alert and run the following command to forcefully terminate the process:

     kill -9 <PID>

  2. If the process cannot be terminated due to self-protection by malicious programs, first run the following command to remove file protection, then forcefully terminate the process:

     chattr -i /path/to/file

  3. Check /etc/crontab and ~/.ssh/authorized_keys to clean up any residues.

• If you confirm that the threat has been cleared, you can select Ignore or Manually Handled to close the alert.

How do I troubleshoot and handle a suspected privilege escalation alert?

1. Confirm whether it is a normal O&M operation: Check whether any administrator performed privilege escalation operations such as sudo, su, or software installation on the host around the alert time. If it is a planned operation, you can ignore or whitelist it.

2. Check suspicious processes and files: Log on to the Security Center console and go to the alert details page to view the process chain and file paths. Focus on checking for any unknown binaries, scripts, or tampered system commands. If accompanied by unusual logon or brute-force alerts, analyze them together with the Unusual Logon alerts.

3. Handling suggestions:

   • If confirmed as malicious, immediately isolate the asset, block the suspicious network connection, and use the Virus Detection and Removal or Vulnerabilities feature of Security Center to clean up backdoors and fix related vulnerabilities.

   • If it is a false positive, click Add to Whitelist on the alert details page.

What should I do if I receive an unusual logon alert on a server configured with SSH key-based logon?

1. Go to the Detection and Response > Alerts page in Security Center to view the remote logon alert details and obtain the logon IP and region information.

   Note

   If you have activated the Agentic SOC service, the left-side navigation pane entry changes to Agentic SOC > Alerts.

2. Log on to the server and check the /var/log/secure log to confirm whether the IP has any successful logon records.

3. If the log shows successful key-based logon, check whether there are any unknown SSH keys on the server. We recommend that you create a new key pair, reconfigure it for use, and reset the server logon password to ensure security.

How do I export the Security Center alert list through the API?

1. Call the ExportSuspEvents - Export unusual event information operation to generate an export task ID.

2. Call the DescribeSuspEventExportInfo - Query alert event export information operation and pass in the task ID.

3. Obtain the link field (download URL) from the returned result.

4. Access the URL from your browser to download the alert list as a ZIP file to your local machine.

What should I do if I get a "Failed to list deduct package" error when handling a crypto-mining alert?

You need to create a cloud disk snapshot and grant the required permissions to troubleshoot the issue.

How do I confirm whether Security Center still detects anomalies after reinstalling the system?

Check the Security Center Alerts page and the server CPU resource usage. If no mining communication is detected in the last few hours and CPU usage returns to normal, the anomaly has been eliminated.

What should I do if CPU usage is high but no mining alert is detected?

1. On the Detection and Response > Alerts page, handle all historical alerts first, and then perform scanning.

   Note

   If you have activated the Agentic SOC service, the left-side navigation pane entry changes to Agentic SOC Alerts.

2. If no virus is found during scanning, the virus has been cleaned up.

3. Check for alerts about Java applications executing suspicious encoded commands or malicious script code execution. We recommend that you contact developers to fix the vulnerabilities in the code and continue to observe.

How do I confirm that a Security Center alert is triggered by my own O&M operations?

Since alerts cannot confirm the specific access IP, we recommend that you verify using the following methods:

1. Check the username and operation time in the alert details to determine whether they match your own O&M behavior.

2. Check the process path (such as /usr/bin/bash) and parent process (such as sshd-session) in the alert details.

3. Verify against logon logs.

4. After handling the alert, test whether your own connection is affected to determine the correlation.

5. Click to authorize Alibaba Cloud Security Large Model on the alert details page to analyze the alert details.

How do I handle alerts caused by StarOPS scheduled inspection tasks?

View the alert details in Security Center to check the relevant alert information. Compare the alert time and alert scanning directory with the StarOPS scheduled inspection task. If you confirm that the alert was caused by a command executed by StarOPS, determine it as a false positive, ignore the alert, and observe subsequent conditions.

What should I do if Security Center still generates security alerts after an instance is unsubscribed or released?

1. Log on to the Security Center console and unbind the corresponding server as described in Manage servers.

2. On the Alerts page, if the server instance has associated unhandled alerts, handle them uniformly as Ignored or Manually Handled.

Causes and troubleshooting methods for internal IP attacks in alerts

Cause

Security Center detects behaviors that match attack signatures (such as brute-force attacks, port scanning, vulnerability exploitation, etc.) initiated by a source IP against a server based on host-level behavior analysis. As long as the behavior is abnormal, an alert is triggered regardless of whether the source IP is a public or internal IP.

Possible scenarios

• Other ECS instances under the same account are compromised or misconfigured, initiating internal attacks.

• Instances in other VPCs access through internal networks via Cloud Enterprise Network (CEN), VPC peering connections, or shared VPCs.

• On-premises data centers connect to the cloud via Express Connect circuits.

• High-frequency internal business requests are misjudged.

Troubleshooting and handling

• Confirm the IP ownership in the ECS console and check whether there are network connectivity configurations such as CEN or peering connections.

• Log on to the Security Center console to check the specific attack type, time, and port to determine whether it is a false positive.

• If confirmed as a trusted internal business, disable the policy for that IP in the IP interception policy and add the IP to the whitelist.

• If the source cannot be determined, we recommend that you keep the interception enabled and check the target server security group to ensure only necessary ports are open.

How do I confirm whether malicious code was planted by a specific person?

Security Center focuses on threat detection and cannot directly identify who planted the malicious code. If you have enabled ActionTrail, we recommend that you review the associated operation records within the alert time window to assist with tracing the source.

What should I do if an abnormal RAM user (sub-account) is created on my Alibaba Cloud account?

Cause

The AccessKey triggered the Alibaba Cloud security risk control rules, detecting "abnormal creation of a high-privilege sub-account", which indicates that the AccessKey may have been leaked.

Handling steps

1. Delete the abnormal RAM user with the Frozen status in the RAM console.

2. Immediately disable and delete all unnecessary AccessKeys. Create a new AccessKey for your business and update the configuration.

3. Log on to the Security Center console and check the Security Alert page to confirm whether there are any other intrusion traces.

4. Enable MFA multi-factor authentication for the primary account and all RAM users.

Is an unusual logon alert a false positive in a scenario where only specific internal IPs are allowed and accessed through a VPN?

Risk assessment

Combined with the security group policy (only allowing specific internal IPs) and VPN access control (only allowing personal remote access), the probability of being attacked externally by malicious actors is low.

Cause

The alert may be caused by log collection issues, non-interactive logon, or a false positive (normal business fluctuations triggering anomaly detection).

Suggestion

After confirming with O&M personnel that the IP is normal, perform Add to Whitelist for that IP in Security Center, take a snapshot backup, and observe whether similar alerts occur subsequently.

How do I recover website accessibility after Security Center detects a backdoor?

1. Log on to the Security Center console and go to the CWPP tab under Detection and Response > Alerts to view the specific alert details.

   Note

   If you have activated the Agentic SOC service, the left-side navigation pane entry changes to Agentic SOC > Alerts.

2. If confirmed as a backdoor file, first create a snapshot backup of the ECS instance, then manually delete or isolate the abnormal file, and check whether the website directory and configuration files are complete.

3. After handling is complete, restart the web service to attempt to restore access.

What should I do if my ECS instance Python environment is repeatedly damaged, causing the website to be unavailable?

1. Log on to the Security Center console to check the alert details and confirm whether there are any critical alerts for Backdoor (WebShell) file discovered.

2. If confirmed as a malicious file, you can choose the handling method described in Virus Detection and Removal to immediately terminate the virus process and move the virus file to the quarantine area.

3. After handling, investigate the cause of the intrusion and harden the system to prevent backdoors from being planted again.

4. If the Python environment cannot be restored after cleaning up the backdoor, further technical support intervention may be required.

What should I do if ECS alerts are not displayed due to instances being in different regions?

Access the Security Center console, go to the Detection and Response > Alerts page, and switch the region to Outside Chinese Mainland to view alerts for ECS instances outside mainland China.

What should I do if the HandleSimilarSecurityEvents operation returns an InvalidOperationForEvent error?

The cause is that the ECS server is currently bound to a Security Center Free edition authorization. The proactive handling features of Security Center, such as quarantining files or terminating processes, require Anti-Virus edition or above authorization. Upgrade your authorization to use the related features for handling alerts.

How do I view historical security alerts for a specific date?

Log on to the Security Center console. In the left-side navigation pane, choose Detection and Response > Alerts to go to the alert list page. Set the time filter condition (for example, select a specific date) to query the historical security alert records for that time period.

What should I do if the console does not display file tamper-proof alert records?

1. In the Security Center console, go to the CWPP tab under Detection and Response > Alerts.

   Note

   If you have activated the Agentic SOC service, the left-side navigation pane entry changes to Agentic SOC > Alert .

2. Confirm that the correct region is selected (for example, Chinese Mainland or Outside Chinese Mainland).

3. In the alert list, locate the alert by filtering the server IP and event type.