In the first part of our research, I demonstrated how we revived the concept of no authentication (null session) after many years. This involved enumerating domain information, such as users, without authentication. I walked you through the entire process, starting with the difference between no-auth in the MS-RPC interfaces and the well-known null session, and ending with the methodology used to achieve our goal.

Today, as promised, we’ll dive into part two. Here, we’ll explore why Windows behaves the way it does – allowing domain information to be enumerated without authentication. I’ll also explain why this activity is difficult to prevent and monitor.

First, we’ll examine why this activity is hard to stop by looking at how WMI works. We’ll also discuss the methods available for detecting and addressing this issue.

After that, we’ll cover some basics about MS-RPC security and how to secure your RPC server. Then we’ll analyze the security of the MS-NRPC interface using two approaches: theoretical insight and reverse engineering to gain a deeper understanding.

So, buckle up and let’s continue our journey!

The group policy that punches your domain in the face

When it comes to stopping certain activities in Windows, group policies are often the first line of defense, and our case is no exception. As we discussed in part one, the Restrict Unauthenticated RPC Clients policy can be used to block no-auth activity against interfaces. This policy comes with three settings: “None”, “Authenticated”, and “Authenticated without exceptions”.

While testing, we discovered that even with the policy set to “Authenticated”, it’s still possible to enumerate domain information using MS-NRPC and network interfaces using the
IObjectExporter interface. Naturally, the next logical step would be to use the “Authenticated without exceptions” setting to completely block such activity.
At first, enabling “Authenticated without exceptions” seems to work perfectly – blocking all enumeration activity with no authentication. Over time, however, we would notice significant issues: many of the domain controller’s functions would stop working. This is not surprising, as Microsoft has explicitly warned that using this policy setting can severely disrupt domain controller functionality. In fact, it has been described as “the group policy that punches your domain in the face,” effectively rendering the domain controller inoperable.

To better understand this issue, let’s use WMI as an example and examine why setting this policy to “Authenticated without exceptions” causes domain functionality to fail.

WMI as DCOM object

Windows Management Instrumentation (WMI) is the infrastructure for managing data and operations on Windows-based operating systems. It’s widely used by system administrators for everyday tasks, including remote management of Windows machines.

To test the effect of setting the Restrict Unauthenticated RPC Clients policy to “Authenticated without exceptions”, let’s try to access WMI on a remote machine using the
wmic command to list processes. In this case, we’ll use valid administrator credentials for the remote machine.

Listing remote processes using wmic

As shown in the screenshot above, the attempt to list remote processes fails with an “Access Denied” error, even with valid administrator credentials. But why does this happen?

Remote WMI access relies on the DCOM architecture. To interact with the WMI server, a DCOM object must first be created on the remote machine. As explained in part one, interfaces such as
IObjectExporter (IOXIDResolver) are responsible for locating and connecting to DCOM objects.
In simpler terms native Windows libraries typically use the
IObjectExporter interface by default during the initial steps of creating a DCOM object, although it is technically optional. When binding the interface, the authentication level is set to “no authentication” (level 1). Next, the libraries use the ServerAlive2 function.
When the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”, it blocks these no-auth activities. This prevents the creation of DCOM objects, so the WMIC command that creates a DCOM object fails and returns an “Access Denied” error, even if the credentials are valid.

Furthermore, since DCOM object creation is integral to many domain controller functions, blocking these activities can disrupt most operations on the domain controller. In short, setting the policy to “Authenticated without exceptions” not only breaks remote WMI access, it also impacts broader domain functionality.

To better understand this behavior, let’s examine what happens under the hood when we set the Restrict Unauthenticated RPC Clients policy to “Authenticated” or “None”. Using Wireshark, we’ll capture the traffic while running the same PowerShell command as before.

Network traffic for remote WMI

In the captured traffic, we can see that before the DCOM object is created, the
IOXIDResolver interface must be bound, and the ServerAlive2 function is called (packets 21-24).
If we inspect packet 21, which contains the bind request, we see that the native libraries bind the interface without authentication – because the authentication length is zero.

Binding without authentication

Next, let’s inspect the traffic when the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”.

Network traffic for WMI

From the captured traffic, we can see several “Access Denied” responses when attempting to call the
ServerAlive2 function with valid credentials. This happens because the policy blocks the no-authentication behavior, effectively stopping the initial binding of the IOXIDResolver interface (which binds without authentication by default). The failure to bind the interface at the beginning of the process is what causes this error, proving that it does not come from WMI itself.

The event that never occurs

As we saw earlier, preventing enumeration of domain information seems impossible, but detecting it might be another story. The first place to look for detection is Windows audit policies. I found the audit policy under event ID 5712, which should generate an event like “Audit RPC Events 5712(S): A Remote Procedure Call (RPC) was attempted.”

However, Microsoft states that this event never occurs, and after enabling this audit policy, I indeed found no related events in the event viewer for any RPC attempts.

The event that never occurs seemed like a dead end for detecting RPC activity. However, after further research, I found two additional ways to detect RPC activity.

The first method is Event Tracing for Windows, which logs RPC-related events. However, it lacks useful details such as the IP address of the RPC client and generates many events, including local RPC activity, making it difficult to parse.

The second method is to use third-party open source software called RPC-Firewall. This tool audits all remote RPC calls, allowing you to track RPC UUIDs and opnums, block specific ones, and filter by source address. It integrates with the event viewer to display logs, as shown in the screenshot below of an RPC event generated by RPC-Firewall.

RPC-Firewall RPC event

Prior to conducting this research, I had found these three ways to detect such activity that I mentioned earlier. However, due to the lack of native detection, the process remains challenging. You can rely on third-party tools or develop your own detection method. But even with these approaches, it’s difficult because you need to identify which machines in your domain are making RPC requests without authentication and track the frequency of this activity.

MS-RPC security

Now let’s explore why Windows behaves this way, why there are issues with policies, and what exceptions really mean. But before diving into all that, we need to discuss MS-RPC security – basically, how to secure your RPC server.

From this point on, I’ll be referring to a new term, the RPC server. The RPC server is where the logic of the interface is defined. A single server can have multiple interfaces.

Securing an RPC server is a complex process because of the variety of access methods, such as named pipes or TCP endpoints. In addition, security measures for RPC servers have evolved over time.

In this research, I will focus on the security methods relevant to our study, but there are several other methods, some of which are described in this post.

Registration flags

When registering an interface for an RPC server, specific flags can be set using the RpcServerRegisterIf2 function. Three flags are of particular relevance:

• RPC_IF_ALLOW_LOCAL_ONLY: Rejects calls from remote clients.
• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH: Invokes a security callback for authentication checks.
• RPC_IF_ALLOW_SECURE_ONLY: Limits connections to clients with an authentication level higher than RPC_C_AUTHN_LEVEL_NONE.

The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag registers a security callback (e.g.,
MySecurityCallback), as shown in the examples below, which takes over security checks from the RPC runtime.

RPCServerRegisterIf2 with security callback

If the callback returns
RPC_S_OK (mapped to 0), the client passes; otherwise, the client fails the security check.

The security callback

By default, the RPC runtime (
rpcrt4.dll library) handles client authentication using mechanisms such as NTLM or Kerberos. However, its behavior is influenced by two factors:

1. The Restrict Unauthenticated RPC Clients policy:
   

• If set to “None”, unauthenticated clients are allowed.
• If set to “Authenticated”, only authenticated clients can connect.

Securing the endpoint

As mentioned earlier, RPC servers can be accessed through various transport layers. For remote connections, TCP ports and named pipes are commonly used.

When registering an endpoint for an RPC server using the RpcServerUseProtseqEp function, you can include a security descriptor (SD) to control who can connect to the endpoint. It’s important to note that this SD only applies to named pipes, not TCP ports. Additionally, it can also be used for local connections using ALPC ports as endpoints.

Securing the interface

Microsoft has introduced a newer version of the RpcServerRegisterIf2 function, called RpcServerRegisterIf3, which allows you to add an optional SD when registering your interface. This enables you to control who can connect directly to the interface.

This security mechanism raises an important question: if an interface has registered an SD, and a client connects via TCP without authentication (authentication level = 1), how is the security check performed? Specifically, what security token is assigned to the client for the SD check?

To answer this, we need to do some reverse engineering magic against the RPC runtime library (
rpcrt4.dll).
The figure below shows the decompiled view from IDA for the function called when a client connects without authentication. As you can see, it uses the ImpersonateAnonymousToken function, which allows the thread to impersonate the system’s anonymous logon token. In other words, a client connecting via a TCP endpoint without authentication is represented as an anonymous user.

Called function for unauthenticated clients

After that, the access check is performed using the AccessCheck function:

Access check

Binding authentication

The final RPC security issue to discuss is binding authentication. As you recall, the authentication method is specified in the binding packet (the first packet in an RPC connection). But what does that mean?

An RPC server can register its preferred authentication method for clients using the RpcServerRegisterAuthInfo function. For instance, in the following example, NTLM authentication is registered as the chosen method.

After that, the client can connect using RPCBindSetAuthInfoEx and specify the correct authentication service and authentication level.

Now that we’ve covered RPC security, it’s time to answer questions about our interface (MS-NRPC): What security is applied on the server that defines this interface, and why were we able to access it without authentication?

To do this, I used two approaches:

1. Surface analysis: I examined the internal security checks of the RPC server using a flowchart from a great RPC toolkit. This chart provides valuable insight for our research, allowing us to analyze the security applied by the RPC server in more detail. I’ll go through it step by step, following the path described in the chart to conduct the investigation.
2. In-depth analysis: In this approach, I interacted directly with the RPC server using reverse engineering to gain further insight into the enabled security.

Surface analysis

I will now attempt to determine the security mechanism used by the RPC server that’s related to the MS-NRPC (Netlogon) interface. I will assume that we are the RPC client calling a function from (MS-NRPC) Netlogon to enumerate domain information without using any authentication.

Let’s start with transport protocols, as outlined in the flowchart:

In the chart above, the RPC client has two options for connecting to the RPC server: via TCP or SMB named pipes. In our research, we are using TCP, which is highlighted.

Next, we encounter the Restrict Unauthenticated RPC Client policy, which has two values: “None” or “Authenticated”. If set to “None”, we proceed to the next step. If set to “Authenticated”, a check is performed to see if the client has authenticated. If it has, the flow continues; however, if the client connects without authentication (as in our case), the RPC runtime checks for the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag and either accepts or denies the connection based on its presence.

Since the policy is set to “Authenticated” and our client does not perform authentication, we need the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag to be registered in order to proceed to the next step, thereby making an exception to the policy. The presence of this flag allows us to conclude that a security callback has also been registered.

Our path now looks like this:

Next, there is another check to see if the server has registered an authentication service. If the server hasn’t registered one and the client tries to authenticate, it will be denied with an “authentication service unknown” error. However, if the client doesn’t attempt authentication, the process continues.

If the server has registered an authentication service, the check against the endpoint (the SD registered via RpcServerUseProtseqEp) is performed. If the client passes this, another check is made against the interface SD (registered using RpcServerRegisterIf3). Failure to pass either of these checks will result in access being denied.

In our case, we know the server has already registered an authentication service because it’s a well-known Microsoft protocol. We don’t need to worry about the endpoint check either, as it’s intended for clients connecting via named pipes. As for the interface security descriptor, we either passed this check if the SD doesn’t exist at all, or the SD does exist and it allows anonymous users (representing clients without authentication).

Next, we check two flags: the first, RPC_IF_ALLOW_LOCAL_ONLY, determines if the interface can be accessed remotely, and the second checks for RPC_IF_ALLOW_SECURE_ONLY. If the latter is present, it ensures that we are using an authentication level higher than “None”, denying or allowing access based on the authentication level. Finally, we check for the presence of a security callback. If it doesn’t exist, we can access the server immediately. If it does exist, we must pass the custom checks within the security callback to access the server.

In our case, we know that RPC_IF_ALLOW_LOCAL_ONLY doesn’t exist because we can access the interface remotely. We also know that RPC_IF_ALLOW_SECURE_ONLY isn’t present because we’re using an authentication level of “None”. Finally, we conclude that a security callback is registered based on the previous use of RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, and we successfully pass the security callback check to gain access to the server.

Our final path looks like this:

Surface analysis conclusion

At this stage, we can conclude that the RPC server has the following characteristics:

1. Regarding registration flags:

• Has RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH (indicating a security callback).
• Doesn’t have RPC_IF_ALLOW_LOCAL_ONLY.
• Doesn’t have RPC_IF_ALLOW_SECURE_ONLY.

• We’re unsure if it has a security descriptor (SD) or not.

• The RPC server registers authentication.

As shown, the surface analysis couldn’t provide a complete security overview for the Netlogon (MS-NRPC) interface, so I decided to proceed with an in-depth analysis.

In-depth analysis

The goal of our in-depth analysis is to leverage reverse engineering techniques to assess the security of the RPC server under the MS-NRPC interface. As we saw before, the interface is accessible through the LSASS process, specifically via the Netlogon DLL. Here we have two approaches to analysis:

1. Use automated tools to examine the security of the interface.
2. Go directly to IDA and manually locate the interface and its associated security mechanisms.

Automated tools

Let’s begin with a tool called PE RPC Scraper. If we provide the Netlogon DLL as an argument, this tool reveals information about the RPC server, its interfaces, functions and security details.

PE RPC Scraper output

The output of the tool shows that it successfully identified the Netlogon interface (UUID) and confirmed that it contains 59 functions. It also revealed the presence of a security callback and a set of flags with a value of
0x91. After decoding this value, we can see that the following flags have been registered:

• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
• RPC_IF_SEC_CACHE_PER_PROC
• RPC_IF_AUTOLISTEN

The output from PE RPC Scraper also indicates that the interface has no security descriptor.

The information obtained from both the surface analysis and the automated tool provides the answer to the security bypass issue and allows me to conclude the investigation at this point. However, I personally don’t trust automated tools, and I have a good reason for that. So, for further confirmation, let’s dive into IDA.

IDA like a superhero

At this point, I’ve loaded
netlogon.dll into IDA and started my investigation.

A. Locate the interface

The first step is to determine where the interface is registered. As shown in the figure below, the UUID registered using RPCServerRegisterIf3 is related to the MS-NRPC interface.

MS-NRPC interface registration

B. Endpoint registration

At this stage, we’ll check the endpoint registration for the server. As you can see in the screenshot below, RpcServerUseProtseqEpW and RpcServerUseProtseqExW have been used to register three endpoints:

1. SMB named pipe, lsass
2. Local ALPC port, NETLOGON_LRPC
3. High dynamic TCP ports

Endpoint registration

C. Interface registration

As I mentioned earlier, RpcServerRegisterIf3 is used to register the interface.

Interface registration

The function used the
0x91 value as a set of flags, which are: RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_SEC_CACHE_PER_PROC | RPC_IF_AUTOLISTEN. RpcServerRegisterIf3 also has a security callback (sub_18002EF60), in addition to a security descriptor (hMem). This finding contradicts what was previously confirmed by an automated tool – that’s why I don’t trust them for reverse engineering.

D. Security callback

Now let’s go inside the security callback and see how the security check is performed. From the screenshot below, we can see that RpcServerInqCallAttributesW is called first with the
Flags field inside the RpcCallAttributes struct set to 96. After decoding this value, we can see that this function used two flags – RPC_QUERY_IS_CLIENT_LOCAL | RPC_QUERY_NO_AUTH_REQUIRED – to request the client information.
The security callback has a condition statement.

The security callback conditions

First, the callback verifies that the RpcServerInqCallAttributesW function was called successfully, then it checks if the opnum is less than 59. If both previous conditions are met and the client is local, access to the server is granted. If the client is remote, the callback uses an access array (a matrix) to determine if the opnum is allowed to be called by the remote client.

The access matrix is just hardcoded bytes in memory:

Access matrix

All of the previously mentioned functions in the MS-NRPC interface that can be accessed without authentication (as outlined in the table in the first part) pass the access matrix check.

Now, let’s analyze what happens when the conditions are met or not, using assembly language since the IDA decompiler tab lacks precise interpretations.

The security callback conditions in assembly

• For the security callback, as we mentioned earlier, returning 0 indicates a successful call.
• For the first condition (RpcServerInqCallAttributesW), failure results in an error value.
• For the second condition (operation number compared to 59), failure still returns 0. This only ensures that the matrix index doesn’t exceed its size and doesn’t validate implemented functions that are handled elsewhere.
• For the third condition, if both the access matrix and local client checks fail, the callback returns 5 (access denied). If either of them succeeds, execution continues.

If all of the above checks in the IF statement are passed, the security callback proceeds to check the Windows version with another IF statement that verifies the value of a DWORD in memory.

The second IF statement

This DWORD is initialized using the code shown below. The value is set based on whether or not the machine is a domain controller (DC).

Checking the machine type

• If the machine is a DC, execution continues and returns 0, indicating that the security callback check was successfully passed.
• If it is not a DC, further checks are performed.

This sequence of checks shows that passing the security callback for the remote client on a DC requires only that the access matrix check be successfully passed.

E. Interface security descriptor

As we saw before, the security descriptor is assigned through the RpcServerRegisterIf3 function. It is set up by calling another function that contains many instructions. The security descriptor definition language (SDDL) for the security descriptor is shown below.

SDDL for security descriptor

From the SDDL, we can see that the following groups of users have read access: Anonymous Logon, Everyone, Restricted Code, Built-in Administrators, Application Package, and a specific security identifier (SID).

But I ran into a problem. The function where the security descriptor is set up contained numerous operations, and I wasn’t sure if any changes had been made to the SDDL representation of the security descriptor. That’s why I decided to find an alternative method to verify that the SDDL interpretation remained the same.

To achieve this goal, I considered two approaches:

1. Memory search: I considered searching memory at runtime for the known value in the header of the relative security descriptor to intercept and extract the discretionary access control list (DACL) inside LSASS. However, since this involves interacting with the LSASS process, which is risky, I took a different approach.
2. ALPC Port Security Descriptor: The ALPC port NETLOGON_LRPC, registered during endpoint setup, shares the same security descriptor as the interface:

Endpoint and interface registration

Using the ALPC port’s name, I used the NtObjectManager PowerShell module (you can use any programming alternative) to extract the security descriptor from the ALPC port.

Extracting the SD from the ALPC port in PowerShell

After that, I obtained the DACL from the security descriptor.

Security descriptor for ALPC port

The screenshot above shows that the DACL obtained from the ALPC port’s security descriptor matches the SDDL representation we obtained earlier. As we can see in the first line of the ACL entries, anonymous login is allowed on the interface, which explains why we can pass the security descriptor access check for the interface (if there is no client token, the Anonymous LOGON token is assigned).

In-depth analysis conclusion

From the in-depth analysis, we now have the whole scenario of the MS-NRPC security mechanism, which allowed us to understand how we could successfully pass the security checks of the MS-NRPC interface and call multiple functions without authentication, even if the RPC policy is set to “Authenticated”.

To summarize, here’s how we were able to bypass the security of MS-NRPC:

1. Registration flags:We found that the interface has the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag: for this reason, we were able to get past the RPC policy.
2. Security callback:We found that this flag has a security callback, which in our case is used to check if we pass the check against the access array, and all of our functions passed the check.
3. Interface security descriptor:

The interface has a security descriptor that permits multiple user groups to connect, including anonymous users. Since we are using no authentication, the access check is performed against the anonymous user, allowing to access the interface’s functions.

Research conclusion

At the end of this part and my research, I hope I was able to provide all the details related to this research and the approaches that I used. I also hope that you are now able to understand why we have this kind of no-authentication enumeration. Furthermore, I hope you are now equipped to develop your own ways to detect this kind of activity.

Thank you for reading, and see you soon with more research projects.

securelist.com/ms-rpc-security…

Gli specialisti IT nordcoreani hanno iniziato a infiltrarsi con più frequenza nelle aziende europee fingendosi dipendenti assunti in full remote. Gli operatori nordcoreani hanno intensificato le operazioni in Germania, Portogallo, Serbia, Slovacchia e altri paesi, utilizzando falsi curriculum, passaporti contraffatti e foto generate dall’intelligenza artificiale per ottenere colloqui di lavoro.

L’obiettivo di questi lavoratori è quello di ottenere un impiego nel settore IT e di inviare i loro stipendi al bilancio di Pyongyang. A volte lanciano malware sui dispositivi aziendali, rubano informazioni riservate ed estorcono denaro. Ci sono anche casi in cui questi specialisti trovano lavoro in più aziende contemporaneamente, ricevendo più stipendi da più organizzazioni, ma contemporaneamente svolgono i loro compiti in modo scadente.

Spesso si usano tattiche per nascondere le origini “webcam rotta” Assistenza VPN e rivenditori locali. Questi ultimi accettano computer portatili aziendali, li mantengono connessi alla rete e aiutano anche a trasferire fondi guadagnati tramite criptovaluta o servizi come Payoneer e TransferWise. Questo schema è stato denominato “La fattoria dei computer portatili” . In un caso, è stato scoperto che un dispositivo aziendale destinato agli Stati Uniti era attivo a Londra, il che indica una catena di fornitura complessa.

L’indagine ha rivelato la presenza di istruzioni dettagliate in materia di impiego su siti web europei, tra cui consigli su come cambiare fuso orario e ottenere una cittadinanza fittizia. Nei documenti si parla di biografie false, con diplomi presumibilmente dell’Università di Belgrado e indirizzi in Slovacchia. Sono stati trovati anche i dettagli di accesso agli account sui siti web di reclutamento e sulle piattaforme di gestione delle risorse umane.

Gli esperti di Google sottolineano che i truffatori prendono sempre più di mira le aziende che adottano la politica BYOD (Bring Your Own Device). Questo approccio consente di lavorare da dispositivi personali non controllati dagli strumenti di sicurezza aziendale ed elimina inoltre la necessità di inviare computer portatili, riducendo così il rischio di esposizione tramite verifica tramite indirizzo.

Si nota che, con la crescente pressione internazionale e le indagini negli Stati Uniti, i dipendenti IT nordcoreani stanno sempre più spostando le loro attività in Europa, dove il livello di consapevolezza di tali schemi è inferiore. Alcuni specialisti hanno iniziato a ricorrere sempre più spesso al ricatto: dopo essere stati licenziati, minacciano di divulgare dati riservati o di passarli ai concorrenti. Le fughe di notizie riguardano codici sorgente e progetti interni.

Le agenzie federali raccomandano di prestare attenzione ai segnali di sostituzione: rifiuto di effettuare videochiamate, frequenti modifiche nei dettagli di pagamento, mancanza di foto nei profili e discrepanze negli indirizzi. Individuare tali abusi diventerà sempre più difficile man mano che i truffatori diventeranno più sofisticati e le grandi aziende tecnologiche diventeranno sempre più i loro bersagli.

L'articolo Quell’accento Nord Coreano ancora trae in inganno! I falsi lavoratori rubano dati e stipendi! proviene da il blog della sicurezza informatica.

You don’t see them as often as you used to, but it used to be common to see “electronics trainers” which were usually a collection of components and simple equipment combined with a breadboard, often in a little suitcase. We think [Pro Maker_101’s] portable electronics workstation is in the same kind of spirit, and it looks pretty nice.

The device uses a 3D printed case and a custom PC board. There are a number of components, although no breadboard. There is a breakout board for Raspberry Pi GPIO, though. So you could use the screw terminals to connect to an external breadboard. We were thinking you could almost mount one as a sort of lid so it would open up like a book with the breadboard on one side and the electronics on the other. Maybe version two?

One thing we never saw on the old units? An HDMI flat-screen display! We doubt you’d make one exactly like this, of course, but that’s part of the charm. You can mix and match exactly what you want and make the prototyping station of your dreams. Throw in a small portable soldering iron, a handheld scopemeter, and you can hack anywhere.

We’d love to see something like this that was modular. Beats what you could build in 1974.

youtube.com/embed/81NDDDT1xus?…

hackaday.com/2025/04/04/a-port…

Il direttore della National Security Agency, il generale dell’aeronautica Timothy Haugh, sarebbe stato licenziato giovedì dal suo incarico di capo dell’agenzia. La rimozione di Haugh dal ruolo di direttore della NSA, la principale agenzia nazionale per lo spionaggio informatico e le intercettazioni elettroniche, avviene nello stesso giorno in cui, secondo quanto riferito, almeno tre membri dello staff del Consiglio per la sicurezza nazionale della Casa Bianca sono stati allontanati.

Il capo del Dipartimento per l’efficienza governativa, Elon Musk, è stato ospitato da Haugh presso la sede centrale della NSA il mese scorso. Si è trattato della sua prima visita nota a un’agenzia di intelligence statunitense. Secondo il Washington Post, il tenente generale William J. Hartmann, vice di Haugh al Cyber ​​Command, assumerà la carica di direttore ad interim della NSA.
Timothy D. Haugh (nato l’11 gennaio 1969) è un generale dell’aeronautica militare degli Stati Uniti che ha prestato servizio come comandante dello United States Cyber ​​Command , direttore della National Security Agency e capo del Central Security Service dal 2024 al 2025. In precedenza ha prestato servizio come vice comandante dello United States Cyber ​​Command
Stando a quanto riportato dal Washington Post, che cita funzionari statunitensi in carica ed ex dirigenti, anche la vice civile del direttore estromesso della NSA, Wendy Noble, è stata licenziata giovedì. Secondo quanto riportato dal quotidiano, a Noble è stato assegnato un nuovo incarico presso l’ufficio del Sottosegretario alla Difesa per l’intelligence del Pentagono .

Il senatore Mark Warner (D-Va.), membro di spicco della Commissione Intelligence del Senato, ha condannato il licenziamento di Haugh. “Il generale Haugh ha servito il nostro paese in uniforme, con onore e distinzione, per più di 30 anni. In un momento in cui gli Stati Uniti stanno affrontando minacce informatiche senza precedenti, come ha chiaramente evidenziato il cyberattacco Salt Typhoon dalla Cina, in che modo licenziarlo rende gli americani più sicuri?” ha scritto Warner su X.

I funzionari statunitensi hanno dichiarato alla testata giornalistica che il motivo dietro il rimpasto della NSA è sconosciuto. Haugh, che è anche capo del Cyber ​​Command del Pentagono, ha guidato la NSA dal febbraio 2024. Non è chiaro se il generale dell’Aeronautica Militare rimarrà al suo posto di comando informatico dopo la sua rimozione dall’agenzia di spionaggio con sede a Fort Meade, nel Maryland.

Il senatore ha anche attaccato il presidente Trump, facendo riferimento alle segnalazioni secondo cui i licenziamenti di membri dello staff del Consiglio per la sicurezza nazionale sarebbero avvenuti subito dopo un incontro con l’influencer di destra Laura Loomer.”È sorprendente che il presidente Trump abbia licenziato il leader imparziale ed esperto della NSA senza riuscire a ritenere responsabile alcun membro del suo team per la fuga di informazioni riservate su un’app di messaggistica commerciale, anche se apparentemente riceve indicazioni sul personale per la sicurezza nazionale da un teorico della cospirazione screditato nello Studio Ovale”, ha scritto Warner in un post separato.

L'articolo Trump silura il capo della NSA! Il Caos Regna sull’intelligence USA dopo gli attacchi di Salt Typhoon proviene da il blog della sicurezza informatica.

La notizia è stata anticipata da politico.eu: a partire da maggio 2025, la Commissione von der Leyen revisionerà il GDPR introducendo semplificazioni. Certo, non sarebbe male pubblicare prima le CVE del Regolamento, ma quel che è stato anticipato riguarda per lo più una generale riduzione degli adempimenti nel settore tech e nelle PMI.

L’obiettivo dichiarato è quello di favorire la competitività, soprattutto nei confronti di Cina e Stati Uniti. Dopo il rapporto Draghi sul futuro della competitività europea, una rilettura degli adempimenti normativi in modo tale che non possano ostacolare l’innovazione e lo sviluppo tecnologico sembrerebbe una strada quasi obbligata. Quasi, perché quella fra innovazione e rispetto delle regole è una falsa dicotomia. La quale è però bastevole a rivelare l’approccio fallimentare dell’Unione Europea nel ritenersi un giardino dei diritti nella giungla internazionale e pretendere la sovraestensione del proprio sistema normativo. La sovranità tecnologia non può certamente essere ottenuta tramite una legge. A meno che, ovviamente, non si disponga la forza di imporla.

Ad ogni modo, sebbene gli eccessi dei vari “Act” e la resistenza a rimettere in discussione più che le regole la loro applicazione siano sotto gli occhi di tutti, il rischio è che in nome di una pretesa semplificazione si vada semplicemente a sostituire un dogma con un altro. Transitando così da un eccesso regolatorio alla promozione di comportamenti spregiudicati, finanche a premiare quanti semplicemente hanno ignorato o eluso l’applicazione del GDPR con la scusa di difficoltà indimostrate. Di fatto, andando ad operare al di fuori delle regole con un vantaggio competitivo indebito rispetto a chi invece ha investito in compliance.

Aree di intervento e principali dubbi

Dopo 7 anni dall’applicazione del GDPR è comunque opportuno trarre un bilancio della norma e metterla in discussione nelle parti in cui ha dimostrato di non funzionare o di avere un impatto eccessivo rispetto ai benefici. Ovviamente, senza snaturarne le finalità di garantire un’elevata protezione dei dati personali e la libera circolazione degli stessi. Anche nei nuovi scenari di competizione sulle tecnologie di Intelligenza Artificiale infatti bisogna ragionare secondo il canone della sostenibilità dell’impiego dei dati personali.

Le semplificazioni trapelate sembrerebbero però collegate alla dimensione dell’organizzazione, secondo un limite che potrebbe essere quello dei 500 dipendenti. Eppure, tale limite non risponde ad alcun tipo di criterio logico dal momento che l’esigenza di una maggiore responsabilizzazione – e dunque: maggiori adempimenti – non è correlabile alle dimensioni dell’organizzazione bensì al volume delle attività di trattamento svolte, alla natura dei dati e ai rischi.

Qualora venga seguita questa direzione, qualche dubbio circa l’approccio della Commissione è inevitabile che sorga. Se questa è la risposta europea ai dazi degli Stati Uniti, infatti, che allora venga dichiarata come tale e non mascherata dai pur condivisibili intenti di semplificazione.

Anche perchè il rischio è che i cittadini perdano ulteriormente fiducia nell’azione delle istituzioni dell’Unione Europea. Fiducia che dopo il QatarGate è stata già profondamente intaccata.

Semplificazione o deregolamentazione?

L’evoluzione sperata verso un GDPR 2.0 deve contemplare principi e framework, valorizzare l’accountability e, soprattutto, promuovere un’applicazione uniforme e coordinata della norma eliminando le incertezze a riguardo. Ben venga ogni semplificazione, purché ovviamente non sacrifichi in modo spoporzionato tanto la protezione degli interessati quanto le strategie e gli investimenti delle aziende data-driven “virtuose”.

Se invece la semplificazione diventa una pretesa indimostrata per giustificare qualsivoglia intervento, allora si apre la strada verso una deregolamentazione di fatto che sembra giovare più agli interessi delle Big Tech che alla competitività delle imprese europee.

Noyb e altri attivisti della privacy hanno denunciato il pericolo della messa in discussione del GDPR derivante dal cedere alla pressione delle azioni di lobbying. Ma poiché la protezione dei dati personali è una libertà fondamentale riconosciuta dall’ordinamento europeo, il nucleo di tutele e garanzie cui provvede continuerebbe comunque a resistere anche nel caso di profonde modifiche della norma. O della tecnologia.

Questo vale e varrà fintanto che i cittadini stessi percepiscano come un valore la protezione dei propri dati personali. E agiscano per difendere i propri diritti, anche per mezzo dei propri rappresentanti.

Non bisogna mai dimenticare infatti che è la domanda a condizionare l’offerta tanto tecnologica quanto politica.

L'articolo Verso il GDPR 2.0 a favore del settore tech e delle PMI, ma a quale costo? proviene da il blog della sicurezza informatica.

Odd hardware designs crop up in art and renders far more frequently than in the flesh, but console modder [GingerOfOz] felt the need to bring [Anh Dang]’s image of the inevitable carcinization of our gaming consoles to life.

Starting with the image as inspiration, [GingerOfOz] got to work in CAD, creating an entirely new shell for the battered PSOne he adopted for the project. The final product is slightly less curvy than the picture, but some artistic license was necessary to go from the page to the real world.

The enclosure itself looks straightforward, if a bit tedious, but the articulating crab controller is a work of art itself. He could’ve made the arms static or non-functional, but they’re a fully-functional PlayStation controller that can move around just like on your favorite crustacean at the beach, minus the pinching. We love this whimsical take on the console mod which is a breath of salty air to the continuous race to get increasingly complex consoles into handheld form, although there’s certainly nothing wrong with that!

If you’re looking for some other console mods, how about this Apple M1 inside a Wii or getting your old Ouya up-and-running again?

youtube.com/embed/dSBNs3TeINc?…

hackaday.com/2025/04/03/playst…

Oracle ha finalmente ammesso di aver subito una grave violazione dei dati, informando privatamente alcuni clienti selezionati dell’incidente di sicurezza, solo pochi giorni dopo essere stata colpita da una class action che accusava il gigante della tecnologia di aver tentato di nascondere la violazione agli utenti interessati.

Secondo Bloomberg, la società ha inoltre informato i clienti che la società di sicurezza informatica CrowdStrike e l’FBI stanno indagando sull’incidente.

Il riconoscimento da parte dell’azienda arriva dopo settimane di smentite e rappresenta un cambiamento significativo rispetto alla sua posizione pubblica sulla questione. La violazione, inizialmente pubblicata su Breachforums il 20 marzo 2025, ha sollevato preoccupazioni sulla sicurezza dell’infrastruttura cloud di Oracle e sulla sua capacità di salvaguardare i dati sensibili dei clienti.

L’attaccante ha anche esfiltrato i file Java Key Store (JKS) e le chiavi Enterprise Manager JPS. Sebbene non siano state esposte informazioni personali identificabili (PII) complete, Oracle ha confermato che i dati compromessi hanno circa 16 mesi.

L’autore della minaccia, identificato come “rose87168“, ha rivendicato la responsabilità della violazione e ha dichiarato di aver avuto accesso a 6 milioni di record di dati. I dati rubati includono, a quanto si dice, nomi utente, indirizzi e-mail, password con hash e credenziali di autenticazione sensibili come Single Sign-On (SSO) e informazioni Lightweight Directory Access Protocol (LDAP).

Secondo quanto riferito, l’aggressore ha avuto accesso già a gennaio 2025 ai server ed è rimasto inosservato fino alla fine di febbraio, quando Oracle ha avviato un’indagine interna. La violazione è stata facilitata da un exploit Java del 2020 che ha consentito all’aggressore di distribuire una web shell e un malware che prendevano di mira il database Identity Manager (IDM) di Oracle.

Oracle ha informato i clienti interessati e ha rafforzato le misure di sicurezza attorno ai suoi server Gen 1. L’azienda ha sottolineato che i suoi server Gen 2 rimangono inalterati e ha negato qualsiasi violazione della sua infrastruttura Oracle Cloud primaria. Nonostante queste rassicurazioni, la società di sicurezza informatica CybelAngel ha riferito che Oracle ha ammesso privatamente l’incidente alle parti interessate e ha confermato l’accesso non autorizzato ai sistemi legacy.

Questa violazione segue un altro recente incidente di sicurezza informatica che ha coinvolto i server legacy Cerner di Oracle Health, dove i dati dei pazienti di organizzazioni sanitarie statunitensi sono stati compromessi. Mentre Oracle sostiene che queste violazioni non sono correlate, la tempistica ha attirato l’attenzione sulla postura di sicurezza complessiva dell’azienda.

L'articolo Oracle ammette privatamente la violazione dei dati verso gli utenti interessati proviene da il blog della sicurezza informatica.

The console wars of the early 1990s had several players, but the battle that mattered was between Nintendo’s SNES and Sega’s Genesis, or Megadrive if you are European. They are both famous for their games, but in terms of software they can only run what’s on a cartridge. The Genesis has a Motorola 68000 on board though, which is capable of far more than just Sonic the Hedgehog. [EythorE] evidently thinks so, because here’s a port of Fusix, a UNIX-like OS, for the Sega platform.

As it stands, the OS is running on the BlastEm emulator, but given a Sega Saturn keyboard or a modified PC keyboard for the Sega, it could be run on real hardware. What you get is a basic UNIX-like OS with a working shell and the usual UNIX utilities. With 64k of memory to play with this will never be a powerhouse, but on the other hand we’d be curious to see it in a working cartridge.

Meanwhile, if the console interests you further, someone has been into its workings in great detail.

Header: Evan-Amos, CC BY-SA 3.0.

hackaday.com/2025/04/03/a-prop…

We’re used to there being an array of high-end microprocessor architectures, and it’s likely that many of us will have sat in front of machines running x86, ARM, or even PowerPC processors. There are other players past and present you may be familiar with, for example SPARC, RISC-V, or MIPS. Back in the 1990s there was another, now long gone but at the time the most powerful of them all, of course we’re speaking of DEC’s Alpha architecture. [JP] has a mid-90s AlphaStation that doesn’t work, and as part of debugging it we’re treated to a description of its unusual boot procedure.

Conventionally, an x86 PC has a ROM at a particular place in its address range, and when it starts, it executes from the start of that range. The Alpha is a little different, on start-up it needs some code from a ROM which configures it and sets up its address space. This is applied as a 1-bit serial stream, and like many things DEC, it’s a little unusual. This code lives in a conventional ROM chip with 8 data lines, and each of those lines contains a separate program selectable by a jumper. It’s a handy way of providing a set of diagnostics at the lowest level, but even with that discovery the weirdness isn’t quite over. We’re treated to a run-down of DEC Alpha code encoding, and should you have one of these machines, there’s all the code you need.

The Alpha was so special in the 1990s because with 64-bit and retargetable microcode in its architecture it was significantly faster than its competitors. From memory it could be had with DEC Tru64 UNIX, Microsoft Windows NT, or VMS, and with the last of which it was the upgrade path for VAX minicomputers. It faded away in the takeover by Compaq and subsequently HP, and we are probably the poorer for it. We look forward to seeing more about this particular workstation, should it come back to life.

hackaday.com/2025/04/03/the-we…

Everyone knows that ultrasonic cleaners are great, but not every device that’s marketed as an ultrasonic cleaner is necessarily such a device. In a recent video on the Cheap & Cheerful YouTube channel the difference is explored, starting with a teardown of a fake one. The first hint comes with the use of the description ‘Multifunction cleaner’ on the packaging, and the second in the form of it being powered by two AAA batteries.

Unsurprisingly, inside you find not the ultrasonic transducer that you’d expect to find in an actual ultrasonic cleaner, but rather a vibration motor. In the demonstration prior to the teardown you can see that although the device makes a similar annoying buzzing noise, it’s very different. Subsequently the video looks at a small ultrasonic cleaner and compares the two.

Among the obvious differences are that the ultrasonic cleaner is made out of metal and AC-powered, and does a much better job at cleaning things like rusty parts. The annoying thing is that although the cleaners with a vibration motor will also clean things, they rely on agitating the water in a far less aggressive way than the ultrasonic cleaner, so marketing them as something which they’re not is very unpleasant.

In the video the argument is also made that you do not want to clean PCBs with an ultrasonic cleaner, but we think that people here may have different views on that aspect.

youtube.com/embed/GUmaT2IhUJo?…

hackaday.com/2025/04/03/teardo…

"Zero Day", su Netflix, interpretato e prodotto da Robert De Niro.

Sei episodi.

Ve lo consiglio.

When you think about the dawn of modern computers, you often think about the work done in the UK and the US. But Australia had an early computer scene, too, and [State of Electronics] has done a series of videos about the history of computers down under. The latest episode talks about SILLIAC, a computer similar to ILLIAC built for the University of Sydney in the late 1950s.
How many racks does your computer fill up? SILLIAC had quite a few.
This episode joins earlier episodes about CSIRAC, and WREDAC. The series starts with the CSIR Mark I, which was the first computer in the southern hemisphere.

The -AC computers have a long history. While you often hear statements like, “…in the old days, a computer like this would fill a room,” SILLIAC, in fact, filled three rooms. The three meters of cabinets were in one room, the power supply in another. The third room? Air conditioning. A lot of tubes (valves, in Australia at the time) generate a lot of heat.

It is hard to put an exact cost on SILLIAC, but the original estimate was about AU£35,200. That sounds modest, but at the time, you could buy about ten suburban homes near Sydney for that price. Like most projects, the cost rose, and completion depended on a larger donation from a horse race. At the end, the cost was about AU£75,000!

SILLIAC had a reputation of being more reliable than some other computers based on the same design. That was probably because most computers use 6J6 tubes, but SILLIAC used 2C51 devices. Bell Labs created the 2C51 for use in undersea cables. Of course, they were also about six times the cost of a 6J6.

The computer did important work until 1968. It was, sadly, dismantled, but pieces of it are hanging around the Powerhouse Museum and at the University as display items.

This series is a great look at what was happening in the computer world south of the equator during these days. While SILLIAC is fascinating, you might want to start with episode 1. Supercomputers have come a long way.

youtube.com/embed/tJdB3QZpVKA?…

hackaday.com/2025/04/03/austra…

All the news that was fit to print. Image via Wikipedia
In the 1982 movie Fast Times At Ridgemont High, a classroom of students receives a set of paperwork to pass backward. Nearly every student in the room takes a big whiff of their sheet before setting it down. If you know, you know, I guess, but if you don’t, keep reading.

Those often purple-inked papers were fresh from the ditto machine, or spirit duplicator. Legend has it that not only did they smell good when they were still wet, inhaling the volatile organic compounds within would make the sniffer just a little bit lightheaded. But the spirit duplicator didn’t use ghosts, it used either methanol (wood alcohol), isopropyl, or, if you were loaded, ethyl alcohol.

Invented in 1923 by Wilhelm Ritzerfeld, ditto machines were popular among schools, churches, and clubs for making copies of worksheets, fliers, and so on before the modern copy machine became widespread in the 1980s. Other early duplicating machines include the mimeograph, the hectograph, and the cyclostyle.

Getting A Handle On Duplication

To use the ditto machine, one would first make a master copy using a special sheet of paper with a special type of waxy ink on the back that dissolves in alcohol. These types of sheets are still around today, in a way — if you’ve ever gotten a tattoo, you know that they don’t usually just freehand it; the artist will draw out your design on special paper that they can then use to lay down a temporary tattoo on your freshly-shaved skin before going for it.
Image via Wikipedia
But don’t get too excited; tattoo transfer sheets aren’t compatible with ditto machines for a number of reasons. As I mentioned, ditto sheets use alcohol to transfer the ink, and tattoo sheets use heat and pressure. They’re too thin for the mechanics of the ditto machine’s drum, anyway.

So once you’ve typed or drawn up your master sheet, you’d mount it on the drum of the ditto machine. Then, with a big crank handle, you’d roll the drum over sheet after sheet until you had what you needed. The average master could make roughly 50 to 500 copies depending a number of factors.

The rise of higher-quality master sheets is largely responsible for this wide range, but there are other factors at play, like the color that gets used. Purple was made from a dye called aniline purple and lasted longest on paper, although there was also green, red, and black. You see a lot of purple dittos because of its vibrancy and the fact that it was highly soluble in alcohol.

The type of paper entered into the equation as well: absorbent paper like newsprint would make fewer copies than smoother, less porous bond paper. And, as you might imagine, dense text and images used more ink and would wear out the master faster.

youtube.com/embed/ccYLLzpeVnU?…

As with many paper-based things from decades ago, the durability of dittoes is not so great. They will fade gradually when exposed to UV light. Although there is no citation, Wikipedia claims that the average ditto would fade in direct sunlight after about a month. It goes on to assume that most ditto machine users printed onto low-quality paper and will eventually “yellow and degrade due to residual acid in the untreated pulp”.

Not a Mimeograph

It’s worth mentioning that mimeographs are not quite the same thing as ditto machines. For one thing, ditto machines were often hand cranked, and many mimeographs were motorized. Interestingly enough, the mimeograph predates the spirit duplicator, having been patented on August 8, 1876 by Thomas Edison and popularized by the A.B. Dick Company in the 1880s.

Also known as stencil duplicators, mimeographs were a competing technology that used ink and stencils to produce 50 to several thousand copies. A special stencil sheet bearing a wax coating would be typed on a regular typewriter with the ribbon disengaged and the machine set to this mode, and/or written or drawn upon using a special stylus and lettering guides.

The stencil sheet would then be fed into the machine, which had a large drum with an ink pad. The mimeograph would then squish ink through the stencil and onto the paper. You can see all this and more in the video below, which illustrates just how much of an art this whole process was compared to makin’ copies today.

youtube.com/embed/gYjj62eGwc8?…

Mimeographs were largely done in black, but color could be done “easily”, as the video demonstrates. You basically had to hand paint the colors onto your stencil. It doesn’t seem as though changing out the giant ink pad was an option. Unlike dittoes, mimeographs required better paper, so they should last longer in theory.

Before You Run Off

Duplication for the common man is as important as the printing press itself. While today you might just set the printer to provide the number of copies you need, the history of duplication shows that we’ve come a long way in terms of effort on the user’s end. Keep this in mind the next time you want to go Office Space on it.

hackaday.com/2025/04/03/ditto-…